What happens
On DSH Desktop, adding a second account in Settings → Command Code → 多账户轮换 looks like it fails: the row keeps its 未保存 badge and the account key never reaches the Host. It does not fail — the edits are staged, and the only control that commits them (the 放弃 / 保存 pair) sits at the very bottom of a long page, several cards below the account card, with no sticky positioning. A user who does not scroll all the way down has no way to discover that a save is pending, and reads the result as "the second account's key cannot be saved".
Steps:
- Settings → Command Code
- In 多账户轮换, click 添加账户, fill
账户备注名 and API 密钥
- The row shows the
未保存 badge and 未配置; nothing is written to disk at any point
- Scroll past 按模型切换账户 → 可见模型 → API 密钥 → 高级设置; only there do
放弃 / 保存 appear
- Click 保存 → the account is written correctly
Because step 4 is easy to miss (the badge in step 3 says "未保存", which reads as an in-page state rather than "go find a button elsewhere"), this is the reported shape of the bug.
Why it is not a write-path bug (verified on this machine)
Before any save:
~/.dsh/settings.yaml → llm-commandcode: held only showSidebarQuota: true, no accounts:, mtime 2026-09-22 15:20~/.dsh/.credentials.yaml → no COMMANDCODE_API_KEY_2 in refs:, mtime 2026-09-20 19:43
After scrolling to the bottom and clicking 保存, both files were written in the same second — 2026-09-23 12:12:42 — with exactly the expected content:
# ~/.dsh/settings.yaml
llm-commandcode:
showSidebarQuota: true
accounts:
- label: Account 2
apiKeyEnv: COMMANDCODE_API_KEY_2# ~/.dsh/.credentials.yaml (refs:)
COMMANDCODE_API_KEY_2: user_…
At the same time the default account's badge read 已配置, so credentials.describe on this page was live and correct throughout. save() → credentials.set(ref, value) + the accounts mutate all work as designed.
Where
lib/client.js — the page footer is rendered unconditionally at the end of CommandCodeSettingsPage (the cc-footer block, ~L4088–4116 in the 0.11.10 bundle: 放弃 + 保存, disabled: !state.dirty || state.invalid || state.saving). Its whole CSS is .cc-footer{justify-content:flex-end;align-items:center;gap:8px;display:flex} (~L6237) — no sticky, no pin.AccountsCard (~L3597+) has no save control of its own; its actions only stage (addAccount / editAccountLabel / editAccountKey / toggleKeyClear), and that staged state is what lights the 未保存 badge.- Card order above the footer is
多账户轮换 → 按模型切换账户 → 可见模型 → API 密钥 → 高级设置, i.e. the commit control is the element furthest from the edits that need it.
README.zh-CN.md:157 (and the English equivalent) reads "在 设置 → Command Code 的「多账户轮换」卡片添加账户并填写备注名与 API key", with no mention of an explicit save step — which sets the expectation that adding the row is enough.
Suggested fix (any one of these closes it)
- Sticky footer — pin
cc-footer to the bottom of the section. Smallest change, no behaviour change.
- Per-card apply — give
多账户轮换 (and 按模型切换账户) their own save action, so a staged card can be committed where it is edited.
- Inline hint — when the account staging is non-empty, render a line in the card pointing at the footer, e.g. 「尚未保存 —— 点击页面底部「保存」生效」. Cheap, and it covers every staged surface on this page.
- README — append 「…然后滚动到页面底部点击「保存」」to the multi-account section.
Environment
@mars-sea/dsh-commandcode-provider 0.11.10- DSH Desktop 2.0.13 (
dsh-plugin-desktop), Windows 11, node v24.18.1
- Engine generation:
@deepseek-ai/dsh 0.1.5-rc.2 — the installSection + settings.yaml generation, so the write path here is settings.installSection + remote.settings mutate, not the 0.1.7 configForms one
- In the same window at the same time: default account
已配置, usage card populated — only the second account appeared stuck
Not filing this as a functional bug: nothing in the write path is wrong. Filing it because the failure mode is indistinguishable from "the key will not save" and costs a user an hour before they find the button.
中文摘要
不是写入失败，是找不到保存按钮。 在 设置 → Command Code → 多账户轮换 里「添加账户」并填好备注名 / API 密钥后，页面只把编辑暂存在该卡片内（行上显示「未保存」），真正提交的唯一入口是整页最底部的「放弃 / 保存」两个按钮——它位于「按模型切换账户 → 可见模型 → API 密钥 → 高级设置」之后，且不是吸底定位，不滚到底根本看不到。实测：滚到底点保存后，~/.dsh/settings.yaml 的 llm-commandcode.accounts 与 ~/.dsh/.credentials.yaml 的 COMMANDCODE_API_KEY_2 在同一秒（2026-09-23 12:12:42）正确落盘，默认账户同时显示「已配置」，说明 credentials.set 与 accounts 写入链路完全正常。建议任选其一：把 cc-footer 改成吸底；或在「多账户轮换」卡片内提供保存入口；或在卡片里给一条「改完请点页面底部保存」的提示（README 的多账户轮换一节也应补上这一步）。
What happens
On DSH Desktop, adding a second account in Settings → Command Code → 多账户轮换 looks like it fails: the row keeps its
未保存badge and the account key never reaches the Host. It does not fail — the edits are staged, and the only control that commits them (the放弃/保存pair) sits at the very bottom of a long page, several cards below the account card, with no sticky positioning. A user who does not scroll all the way down has no way to discover that a save is pending, and reads the result as "the second account's key cannot be saved".Steps:
账户备注名andAPI 密钥未保存badge and未配置; nothing is written to disk at any point放弃/保存appearBecause step 4 is easy to miss (the badge in step 3 says "未保存", which reads as an in-page state rather than "go find a button elsewhere"), this is the reported shape of the bug.
Why it is not a write-path bug (verified on this machine)
Before any save:
~/.dsh/settings.yaml→llm-commandcode:held onlyshowSidebarQuota: true, noaccounts:, mtime2026-09-22 15:20~/.dsh/.credentials.yaml→ noCOMMANDCODE_API_KEY_2inrefs:, mtime2026-09-20 19:43After scrolling to the bottom and clicking 保存, both files were written in the same second —
2026-09-23 12:12:42— with exactly the expected content:At the same time the default account's badge read
已配置, socredentials.describeon this page was live and correct throughout.save()→credentials.set(ref, value)+ theaccountsmutate all work as designed.Where
lib/client.js— the page footer is rendered unconditionally at the end ofCommandCodeSettingsPage(thecc-footerblock, ~L4088–4116 in the 0.11.10 bundle:放弃+保存,disabled: !state.dirty || state.invalid || state.saving). Its whole CSS is.cc-footer{justify-content:flex-end;align-items:center;gap:8px;display:flex}(~L6237) — no sticky, no pin.AccountsCard(~L3597+) has no save control of its own; its actions only stage (addAccount/editAccountLabel/editAccountKey/toggleKeyClear), and that staged state is what lights the未保存badge.多账户轮换→按模型切换账户→ 可见模型 → API 密钥 → 高级设置, i.e. the commit control is the element furthest from the edits that need it.README.zh-CN.md:157(and the English equivalent) reads "在 设置 → Command Code 的「多账户轮换」卡片添加账户并填写备注名与 API key", with no mention of an explicit save step — which sets the expectation that adding the row is enough.Suggested fix (any one of these closes it)
cc-footerto the bottom of the section. Smallest change, no behaviour change.多账户轮换(and按模型切换账户) their own save action, so a staged card can be committed where it is edited.Environment
@mars-sea/dsh-commandcode-provider0.11.10dsh-plugin-desktop), Windows 11, node v24.18.1@deepseek-ai/dsh0.1.5-rc.2 — theinstallSection+settings.yamlgeneration, so the write path here issettings.installSection+remote.settingsmutate, not the 0.1.7configFormsone已配置, usage card populated — only the second account appeared stuckNot filing this as a functional bug: nothing in the write path is wrong. Filing it because the failure mode is indistinguishable from "the key will not save" and costs a user an hour before they find the button.
中文摘要
不是写入失败，是找不到保存按钮。 在 设置 → Command Code → 多账户轮换 里「添加账户」并填好备注名 / API 密钥后，页面只把编辑暂存在该卡片内（行上显示「未保存」），真正提交的唯一入口是整页最底部的「放弃 / 保存」两个按钮——它位于「按模型切换账户 → 可见模型 → API 密钥 → 高级设置」之后，且不是吸底定位，不滚到底根本看不到。实测：滚到底点保存后，
~/.dsh/settings.yaml的llm-commandcode.accounts与~/.dsh/.credentials.yaml的COMMANDCODE_API_KEY_2在同一秒（2026-09-23 12:12:42）正确落盘，默认账户同时显示「已配置」，说明credentials.set与accounts写入链路完全正常。建议任选其一：把cc-footer改成吸底；或在「多账户轮换」卡片内提供保存入口；或在卡片里给一条「改完请点页面底部保存」的提示（README 的多账户轮换一节也应补上这一步）。