@mars-sea/dsh-commandcode-provider 0.10.3 → 0.10.5

package/CHANGELOG.md

@@ -4,6 +4,43 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.10.5] - 2026-09-11
+
+### Added
+- **The terminal settings page lists every model as a checkbox.** The TUI's model allowlist was a text field expecting comma-separated catalog ids typed from memory; it now renders the whole catalog under plan-tier headings (Go → GOAT → Pro → Provider), free models first, each row carrying its plan/deal/context summary as the footer hint. Everything reads as checked until something is excluded, matching the adapter's "an unset allowlist shows every model" rule, and a model this build does not recognize (retired upstream, or added after this release) still gets a row of its own instead of becoming impossible to switch from the terminal.
+- **`Config.modelVisibility`, a per-model override layer beside `visibleModels`.** The TUI cannot add an id to the array it edits, so each checkbox records `modelVisibility.<id>` (true listed / false hidden) instead; an id absent from the map keeps following `visibleModels`, and the subscription-tier filter still applies on top. A hand-edited document carrying a non-boolean entry falls back to the array rather than hiding the model.
+
+### Fixed
+- **The terminal model checkboxes now save the model you toggled.** dsh-TUI keys a staged edit by the field's PATH, so the whole list of checkboxes sharing one `visibleModels` path shared one draft: each of them parsed that same draft on save, every write op addressed the same path, and only the last field's op survived — silently replacing the allowlist with what the last catalog model's row evaluated to instead of the row the user had switched. Each checkbox now addresses a path of its own, and a toggle writes only when it disagrees with the inherited state, so switching a model back leaves no residue in the document.
+
+### Changed
+- **Per-release compatibility now covers dsh `0.1.5-rc.2`.** `dsh.compatibility.dshReleases` declares it `compatible` alongside `0.1.2-rc.1`, `0.1.3-alpha.1`, `0.1.3-alpha.2`, `0.1.5-alpha.1` and `0.1.5-rc.1`, so the DSH STORE can list the plugin for the current Harness release. Verified on a dsh-TUI profile running that engine: the `/settings` → Command Code page, the model checkbox list, and the picker's catalog all behave as they do on 0.1.5-rc.1. An older release keeps its own record rather than being replaced, so a user who has not moved to the newest engine still sees the listing.
+
+### Documentation
+- **The install and update instructions now say which profile receives the plugin and how to escape pnpm's release-age gate** (both READMEs). A `dsh-tui` profile owns its own plugin list, so the web install does not reach the terminal: the terminal UI needs its own `dsh plugin --profile dsh-tui add`, and it now shows an exact version because a bare package name — or `@latest` — is silently resolved to the previous release for the first 24 hours after a publish (pnpm 11's `minimumReleaseAge`) and the install still exits successfully, which is how a fresh terminal install can end up with no Command Code settings page and no `commandcode` models at all.
+
+## [0.10.4] - 2026-09-11
+
+### Added
+- **A Command Code page in the dsh-TUI settings screen** ([#28](https://github.com/Mars-Sea/dsh-commandcode-provider/issues/28)). The terminal front door now lists Command Code under `/settings`, with the API key, the API base, the out-of-plan model filter, the model allowlist, the active account, and the command language. The key is a write-only credential field: the literal goes to the credential store and never into a settings document, and the field shows only whether one is configured. Until now a TUI-only user had no way to enter a key at all — dsh-TUI's own `/provider` wizard manages its `llm-pi-ai` routes exclusively, and the web Models page was the only surface that could write it. The page appears only on a profile that mounts dsh-TUI; everywhere else the plugin stays a plain LLM-provider bundle. Every model list and account choice reads live settings, so a change lands on the next request with no restart.
+
+### Changed
+- **Per-release compatibility now covers dsh `0.1.5-rc.1`.** `dsh.compatibility.dshReleases` declares it `compatible` alongside `0.1.2-rc.1`, `0.1.3-alpha.1`, `0.1.3-alpha.2` and `0.1.5-alpha.1`, so the DSH STORE can list the plugin for the current Harness release. Verified on both surfaces: the web profile runs the plugin on this engine (settings page, Models-page card, chat and the `/commandcode` dashboard), and a dsh-TUI 0.10.0 profile selects and serves Command Code there. An older release keeps its own record rather than being replaced, so a user who has not moved to the newest engine still sees the listing.
+
+### Security
+- **A literal API key in the composition config no longer rides a settings response.** The `apiKey` fields (top-level and per extra account) are now declared `role('secret')`, so the harness strips them from every settings descriptor it serves. The settings page was already writing keys through the credentials seam — which is what keeps them out of a settings document — but a key written by hand into `cordis.patch.yml` or `settings.yaml` was returned to the browser verbatim, including on a remote-Host setup where that means another machine.
+- **A web page can no longer cancel a login in progress.** The loopback callback's denial branch now checks the login's state token before it ends the attempt, matching the official CLI. A denial is terminal, and the browser sends a `text/plain` POST as a CORS simple request regardless of the origin allowlist, so any open page could previously kill the attempt (and show "authorization denied") by blindly posting `{"error":"access_denied"}` to the loopback port. A denial that carries the real token still ends the attempt, as the Studio's own flow does.
+
+### Fixed
+- **Cancelling a login now really cancels it.** The key delivered by the callback is validated against `/alpha/whoami` before it is stored, and cancelling during that check was ignored: the credential was written anyway and the state flipped back to success while the page (which had already stopped polling) kept showing "cancelled". The completion now re-checks that it still owns the attempt — before writing the key and before publishing any status — so a cancel or a newly started attempt wins.
+- **"Sign in" after a completed callback starts a fresh attempt.** Once the callback is consumed the loopback server is closed, but the status still read `waiting`, so the next sign-in handed back the previous attempt's URL — a link to a dead port. A `waiting` status whose server is gone is now retired instead of reused.
+- **Saving the settings page no longer deletes account entries it cannot show.** The accounts list is written whole, and the page rebuilt it from the rows it displays — so a composition-config entry carrying a literal `apiKey` (which has no row) was silently deleted by any save, and the literal key of the entries it could show was stripped. The write now starts from the stored list and only rewrites the rows the page manages, so unknown entries and literal keys survive.
+- **A failed save no longer throws away what you typed.** Two staged edits were cleared even when the failing write never ran: an account's label reverted to the generated name (and was then persisted that way on the retry), and a routing-rule edit was silently reverted with the page left clean — no dirty marker and no way to retry. Both are now kept until the stored section proves the write landed. Rule drafts are still dropped once the rules write itself lands, because the positional row ids shift and a kept draft would be applied to the wrong row.
+- **The "clean up stale models" button no longer empties the allowlist while the catalog is missing.** Before the first catalog fetch lands — and after a failure — the catalog is empty, so every selected model looked retired and one click cleared the whole list. The cleanup, and its hint, are now shown only when a catalog is actually in hand; the explicit "show all" action remains available.
+- **Whitespace around a stored API key no longer breaks multi-account rotation.** The account pool marked a rejected key exactly as it was stored, while the request path trims it (a key from the credentials seam, a `.env` line, or a shell export picks up surrounding whitespace), so a 429/401 mark landed on a string nothing looked up again: the same account was offered again, the account card showed no mark, and the usage endpoints failed while chat kept working. Keys are now normalized once, where a slot's key enters the pool.
+- **Images returned by a tool are no longer invisible to Vision models** ([#30](https://github.com/Mars-Sea/dsh-commandcode-provider/issues/30)). When the agent read a local image with `read_image` (an absolute path in the prompt) instead of receiving it as an attachment or pasted image, the request replayed only the tool's metadata text — the nested `image` block inside the tool result was flattened away, so the model answered that it could see no pixels. Both transports now carry the image's bytes in a user message right after the tool message, introduced by an `Attached image(s) from tool result:` note: the image stays outside the tool result, where neither `/alpha/generate`'s text-only tool output nor Chat Completions' `role: 'tool'` content could hold it. A tool result that repeats one attachment sends it once, an image-only result no longer produces an empty tool message, and text-only tool results are byte-for-byte unchanged.
+- **Test coverage for the above**, plus the previously unpinned paths they exposed: account writes preserving composition entries, label/rule drafts across every failure order, the login callback's authentication and attempt ownership, credential normalization in the pool, and the catalog-readiness gate (each verified by reverting its fix and watching the new test fail).
+
 ## [0.10.3] - 2026-09-10
 
 ### Changed

package/README.md

@@ -18,6 +18,7 @@ Unofficial [DeepSeek Harness](https://deepseek-harness.github.io/deepseek-harnes
 
 - **Plugin bundle** — install into any dsh profile with `dsh plugin add`; registers a `commandcode` provider route with a live model catalog.
 - **Dedicated settings page** — API key, connection options, a live account-usage card, and a "Hide out-of-plan models" toggle.
+- **Works in the terminal too** — the same install serves a [dsh-TUI](#terminal-ui-dsh-tui) profile, with its own **`/settings` → Command Code** page for the API key and the model controls.
 - **Models-page key card** — the **Settings → Models → Command Code** card carries the key status, a paste field, and the sign-in button inline.
 - **In-browser sign-in for keys** — start the official authorization flow (the same one `cmd login` runs) from the settings page; the approved key lands in the local credential service automatically. Manual paste remains the fallback.
 - **Multi-account rotation** — when one account hits its usage limit, requests switch to the next account automatically. See [Account rotation](#account-rotation).
@@ -46,7 +47,15 @@ Pick the release line that matches your DeepSeek Harness version:
   dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@0.9.1
   ```
 
-> The `latest` tag now always points at the current 0.1.2-line plugin release, so a plain `@latest` install gets the newest stable release for dsh 0.1.2+. Users on the old 0.5.0-era Harness line must pin `@0.9.1` explicitly.
+> The `latest` tag points at the current 0.1.2-line plugin release. Users on the old 0.5.0-era Harness line must pin `@0.9.1` explicitly.
+
+**pnpm 11 holds back new releases.** Its `minimumReleaseAge` defaults to 1440 minutes, so a version published less than a day ago is skipped and `@latest` resolves to the *previous* release — silently, with a success exit code. To install a release from the last 24 hours, name it exactly:
+
+```sh
+dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@0.10.5
+```
+
+The same applies to every profile you install into, including the terminal UI below.
 
 Fresh pnpm 10 marketplace generations are supported directly. Do not add a separate `@deepseek-ai/dsh-invariants` dependency; the plugin declares it as a Host peer so the active dsh profile remains the owner of Harness packages.
 
@@ -59,6 +68,14 @@ dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest     #
 dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@0.9.1      # older dsh (0.5.0 line, unmaintained)
 ```
 
+Each profile updates separately — the terminal UI owns its own plugin list (see below):
+
+```sh
+dsh plugin --profile dsh-tui update @mars-sea/dsh-commandcode-provider@0.10.5
+```
+
+To move to a version published less than 24 hours ago, name it exactly as in Install above; pnpm 11's age gate resolves `@latest` to the previous release instead.
+
 Then restart the web app.
 
 ## Getting an API key
@@ -78,6 +95,51 @@ Or skip the CLI: click **Sign in to Command Code** under **Settings → Command
 
 After restart, enter your API key in **Settings → Command Code** and save; **Settings → Models** shows a **Command Code** card, and the model picker lists the live catalog under **commandcode**. Send a message with a model your plan includes.
 
+## Terminal UI (dsh-TUI)
+
+The plugin also works under a terminal front door. **Each dsh profile owns its own plugin list**, so the web install above does not reach the terminal — add the plugin to the `dsh-tui` profile as well:
+
+```sh
+dsh plugin --profile dsh-tui add @mars-sea/dsh-commandcode-provider@0.10.5
+```
+
+Pin the exact version here. For the first 24 hours after a release, a bare package name (or `@latest`) is silently resolved to the previous one: the install succeeds, but the profile gets the older build — which is how a fresh terminal install ends up with no **`/settings` → Command Code** page and no `commandcode` models at all.
+
+Then pick the provider in the model selector, or name it directly:
+
+```text
+/model commandcode/deepseek/deepseek-v4.1-flash
+```
+
+`/model` lists every registered provider, with Command Code's live catalog and its plan/deal/context annotations. The `/commandcode` usage dashboard works there too.
+
+**Entering the key.** The TUI has no web Models page, so the plugin declares its own page in the TUI settings screen — **`/settings` → Command Code** — with the API key, the API base, the out-of-plan model filter, the active account, and the command language. The key field is write-only: it shows whether a key is configured and writes what you type to the credential store, never to a settings document. The same page is the only place a TUI-only user needs to visit.
+
+**Picking models.** That page lists the whole catalog as checkboxes, grouped by plan tier (Go → GOAT → Pro → Provider) with the free models first, so nothing has to be typed from memory. Everything starts checked, because an unset allowlist means "show every model" — uncheck the ones you do not want in the picker. The choice is stored as per-model overrides next to the `visibleModels` list the web page edits, so both surfaces can be used interchangeably and a plain `visibleModels` written by hand still works.
+
+Alternatively, set the key outside the TUI — any of these work, in this order of precedence:
+
+```sh
+export COMMANDCODE_API_KEY="user_..."   # launching environment
+cmd login                               # writes ~/.commandcode/auth.json
+```
+
+**Making Command Code the default.** dsh-TUI pins its own agent route, and its `agent-default-model` setting does not override it. To start every session on Command Code, override the `agent-loop` row in your profile patch (`$DSH_HOME/profiles/dsh-tui/cordis.patch.yml`):
+
+```yaml
+- id: agent-loop
+  inject: [tuiStartup]
+  config:
+    agents:
+      - id: main
+        provider: commandcode
+        model: deepseek/deepseek-v4.1-flash
+        reasoningEffort: max
+        cwd: !!js process.cwd()
+```
+
+**Engine version.** The plugin needs a dsh engine that exports `ToolCallId` from `@deepseek-ai/dsh-llm` — **dsh 0.1.2-alpha.3 or later**. That includes the engine dsh-TUI recommends (0.1.2-rc.1) and every later release, but *not* the oldest engines its peer range nominally allows: on dsh 0.1.0-rc.6 or 0.1.1-rc.2 the plugin's module import fails and the TUI will not start. Upgrade the engine, or use the web profile.
+
 ## Usage dashboard
 
 The plugin registers a `/commandcode` slash command showing per-account usage:

package/README.zh-CN.md

@@ -18,6 +18,7 @@
 
 - **插件包**：一条 `dsh plugin add` 命令安装到任意 dsh 配置，注册 `commandcode` provider 路由，带实时模型目录。
 - **专属设置页**：API key 输入、连接参数、实时「账户用量」卡片和「隐藏套餐外模型」开关。
+- **终端界面同样可用**：同一次安装即可服务 [dsh-TUI](#终端界面dsh-tui) 配置，终端里有自己的 **`/settings` → Command Code** 页面来填 key 和调模型。
 - **Models 页快捷卡片**：**设置 → Models → Command Code** 卡片内直接显示 key 状态、粘贴输入框和登录按钮。
 - **浏览器内登录获取 key**：设置页一键发起官方授权（与 `cmd login` 同一流程），完成后密钥自动写入本机凭据服务，无需手动创建或粘贴；不可用时随时退回手动粘贴。
 - **多账户轮换**：一个账户用量打满后，请求自动切换到下一个账户。详见[多账户轮换](#多账户轮换)。
@@ -44,7 +45,15 @@
   dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@0.9.1
   ```
 
-> `latest` tag 现在始终指向当前 0.1.2 线的插件版本，普通 `@latest` 安装即可获得 dsh 0.1.2+ 的最新稳定版。旧 0.5.0 时代的 Harness 用户必须显式钉住 `@0.9.1`。
+> `latest` tag 指向当前 0.1.2 线的插件版本。旧 0.5.0 时代的 Harness 用户必须显式钉住 `@0.9.1`。
+
+**pnpm 11 会拦下刚发布的新版本。** 它的 `minimumReleaseAge` 默认为 1440 分钟，发布不足一天的版本会被跳过，`@latest` 解析到**上一个**版本 —— 而且是静默的，命令照样以成功退出。想装 24 小时内发布的版本，必须写精确版本号：
+
+```sh
+dsh plugin --profile web add @mars-sea/dsh-commandcode-provider@0.10.5
+```
+
+这一点对每个 profile 都成立，包括下面的终端界面。
 
 插件可直接在 pnpm 10 的全新插件市场 generation 中安装。不要另行添加 `@deepseek-ai/dsh-invariants` dependency；插件已将其声明为 Host peer，Harness 包仍由当前 dsh profile 统一管理。
 
@@ -57,6 +66,14 @@ dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@latest     #
 dsh plugin --profile web update @mars-sea/dsh-commandcode-provider@0.9.1      # 更早的 dsh（0.5.0 线，不再维护）
 ```
 
+每个 profile 各自更新 —— 终端界面有独立的插件列表（见下文）：
+
+```sh
+dsh plugin --profile dsh-tui update @mars-sea/dsh-commandcode-provider@0.10.5
+```
+
+要更新到发布不足 24 小时的版本，和上面的安装一样写精确版本号；pnpm 11 的年龄门禁会把 `@latest` 解析成上一个版本。
+
 然后重启 Web 应用。
 
 ## 获取 API key
@@ -76,6 +93,51 @@ cmd login        # macOS/Linux；Windows 原生版：cmdc login
 
 重启后，在 **设置 → Command Code** 填入 API key 并保存；**设置 → Models** 出现 **Command Code** 卡片，模型选择器在 **commandcode** 下列出实时目录。选择套餐内包含的模型发送消息即可。
 
+## 终端界面（dsh-TUI）
+
+插件同样支持终端前端。**每个 dsh profile 有独立的插件列表**，所以上面那条 Web 安装命令不会装到终端里 —— 还要把插件装进 `dsh-tui` profile：
+
+```sh
+dsh plugin --profile dsh-tui add @mars-sea/dsh-commandcode-provider@0.10.5
+```
+
+这里请写精确版本号。新版本发布后的 24 小时内，只写包名（或 `@latest`）会被静默解析到上一个版本 —— 安装命令照样成功，但 profile 里拿到的是旧版本，结果就是全新的终端安装里既没有 **`/settings` → Command Code** 页面，也看不到任何 `commandcode` 模型。
+
+之后在模型选择器里选，或者直接指定：
+
+```text
+/model commandcode/deepseek/deepseek-v4.1-flash
+```
+
+`/model` 会列出所有已注册的 provider，Command Code 的实时目录连同套餐/优惠/上下文标注一起出现，`/commandcode` 用量面板在终端里同样可用。
+
+**填写 API key。** 终端没有网页版 Models 页面，所以插件会在终端设置页里声明自己的页面 —— **`/settings` → Command Code** —— 包含 API key、API 地址、隐藏套餐外模型、当前账号和命令语言。key 字段是只写的：它只显示"是否已配置"，输入的内容写进凭据库，不会写进任何 settings 文档。只用终端的用户只需要访问这一个页面。
+
+**选择模型。** 同一页面把整个模型目录列成勾选框，按套餐档位分组（Go → GOAT → Pro → Provider），免费模型排在最前，不需要手打任何模型 id。默认全部勾选——未设置白名单就等于"显示全部模型"；把不想在选择器里看到的取消勾选即可。选择会以「单模型覆盖」的形式保存在网页端编辑的 `visibleModels` 列表旁边，两个界面可以混用，手写的 `visibleModels` 也照常生效。
+
+也可以在终端外配置 key，以下三种方式按优先级生效：
+
+```sh
+export COMMANDCODE_API_KEY="user_..."   # 启动环境变量
+cmd login                               # 写入 ~/.commandcode/auth.json
+```
+
+**把 Command Code 设为默认模型。** dsh-TUI 写死了自己的 agent 路由，它的 `agent-default-model` 设置不会覆盖它。要让每个会话默认走 Command Code，请在自己的 profile patch（`$DSH_HOME/profiles/dsh-tui/cordis.patch.yml`）里覆盖 `agent-loop` 行：
+
+```yaml
+- id: agent-loop
+  inject: [tuiStartup]
+  config:
+    agents:
+      - id: main
+        provider: commandcode
+        model: deepseek/deepseek-v4.1-flash
+        reasoningEffort: max
+        cwd: !!js process.cwd()
+```
+
+**引擎版本要求。** 插件需要导出了 `ToolCallId` 的 dsh 引擎，即 **dsh 0.1.2-alpha.3 或更高**。这覆盖了 dsh-TUI 推荐的引擎（0.1.2-rc.1）以及之后的所有版本，但不包含它 peer 范围里名义上允许的最老引擎：在 dsh 0.1.0-rc.6 / 0.1.1-rc.2 上，插件的模块导入会失败，TUI 无法启动。请升级引擎，或改用 web profile。
+
 ## 用量面板
 
 插件注册了 `/commandcode` 斜杠命令，显示各账户的用量状态：

package/lib/client.js

@@ -312,6 +312,14 @@ window.__ModuleLoader__.load({
 			return b.every((id) => set.has(id));
 		}
 		/**
+		* Order-sensitive content fingerprint of the stored routing rules. Stored rule
+		* ids are positional (`rule-<index>`), so equality of this fingerprint across a
+		* save is exactly the statement "no rules write landed and no row shifted".
+		*/
+		function ruleFingerprint(rules) {
+			return JSON.stringify(rules.map((rule) => [rule.models, rule.account]));
+		}
+		/**
 		* Controller bridging the `llm-commandcode` scope and the credentials domain
 		* onto the page. Public API mirrors the harness's CardForm actions, so the
 		* component stays thin.
@@ -351,6 +359,12 @@ window.__ModuleLoader__.load({
 			* would delete the wrong row).
 			*/
 			removedRuleIds = /* @__PURE__ */ new Map();
+			/**
+			* Fingerprint of the stored routing rules when the last `save()` started;
+			* `undefined` outside a save. Lets reconcile distinguish a landed rules
+			* write from a save that failed before reaching it.
+			*/
+			rulesBeforeSave = void 0;
 			/** Staged visible-model allowlist (undefined = no draft). */
 			visibleModelsDraft = void 0;
 			/** The catalog the model editors offer (Host-side). */
@@ -646,6 +660,7 @@ window.__ModuleLoader__.load({
 				}
 				this.saving = true;
 				this.failed = false;
+				this.rulesBeforeSave = ruleFingerprint(this.storedRules());
 				this.publish();
 				let landed = true;
 				for (const run of [
@@ -682,10 +697,10 @@ window.__ModuleLoader__.load({
 			}
 			/**
 			* Drop account staging the stored section already reflects: additions whose
-			* ref is now stored, removals whose ref is gone, and label drafts matching
-			* the stored label. Key drafts are kept — a landed key write is idempotent
-			* on retry, and the draft carries the user's intent when it was the
-			* accounts write that failed.
+			* ref is now stored, removals whose ref is gone, and label drafts that the
+			* stored label proves landed. Key drafts are kept — a landed key write is
+			* idempotent on retry, and the draft carries the user's intent when it was
+			* the accounts write that failed.
 			*/
 			reconcileAccountStaging() {
 				const stored = new Set(this.storedExtras().map((extra) => extra.ref));
@@ -693,7 +708,7 @@ window.__ModuleLoader__.load({
 				for (const ref of [...this.removedRefs]) if (!stored.has(ref)) this.removedRefs.delete(ref);
 				for (const [ref, text] of [...this.labelDrafts]) {
 					const storedLabel = this.storedExtras().find((extra) => extra.ref === ref)?.label;
-					if (storedLabel === void 0 || storedLabel === text.trim()) this.labelDrafts.delete(ref);
+					if (storedLabel !== void 0 && storedLabel === text.trim()) this.labelDrafts.delete(ref);
 				}
 				for (const ref of [...this.keyClears]) if (this.credentialStates.get(ref)?.configured !== true) this.keyClears.delete(ref);
 			}
@@ -861,14 +876,25 @@ window.__ModuleLoader__.load({
 					this.catalogFailed = true;
 				}).then(() => this.publish());
 			}
-			/** The stored extra accounts from the settings section (`accounts`). */
-			storedExtras() {
+			/** The raw `accounts` array of the stored section, verbatim. */
+			rawStoredAccounts() {
 				const raw = this.scope.getSnapshot().value?.accounts;
 				if (!Array.isArray(raw)) return [];
+				return raw.filter((entry) => typeof entry === "object" && entry !== null && !Array.isArray(entry));
+			}
+			/**
+			* The stored extra accounts from the settings section (`accounts`): the rows
+			* this page can address, i.e. the ones carrying a credential reference.
+			*
+			* Entries the page cannot name are deliberately NOT listed here but are also
+			* never dropped — `writeAccounts()` rebuilds the stored list from
+			* {@link rawStoredAccounts} and only rewrites the reference-carrying entries
+			* it manages (see the note there), so a literal-key entry stays in the
+			* document and simply has no row.
+			*/
+			storedExtras() {
 				const out = [];
-				for (const entry of raw) {
-					if (typeof entry !== "object" || entry === null || Array.isArray(entry)) continue;
-					const record = entry;
+				for (const record of this.rawStoredAccounts()) {
 					const ref = record.apiKeyEnv;
 					if (typeof ref !== "string" || ref === "") continue;
 					const label = record.label;
@@ -945,20 +971,54 @@ window.__ModuleLoader__.load({
 				runs.push(() => this.writeAccounts());
 				return runs;
 			}
-			/** Persist the staged accounts list into the settings section. */
+			/**
+			* Persist the staged accounts list into the settings section.
+			*
+			* The stored list is the base — NOT a list rebuilt from this page's rows.
+			* A composition-config entry may carry a literal `apiKey` (or a shape this
+			* page does not know), and the settings layer replaces the whole array, so a
+			* rebuilt list would silently delete every entry the page cannot name along
+			* with the literal keys of the entries it can. Entries are therefore carried
+			* over verbatim and only the reference-carrying rows are rewritten (label
+			* draft applied, staged removals dropped, staged additions appended).
+			*/
 			async writeAccounts() {
-				const base = [...this.storedExtras().filter((extra) => !this.removedRefs.has(extra.ref)), ...this.addedAccounts];
-				const seen = /* @__PURE__ */ new Set();
-				const list = base.filter((extra) => !seen.has(extra.ref) && (seen.add(extra.ref), true)).map((extra) => {
-					const draft = this.labelDrafts.get(extra.ref)?.trim();
-					return {
-						label: draft !== void 0 && draft !== "" ? draft : extra.label,
-						apiKeyEnv: extra.ref
-					};
-				});
+				const removed = this.removedRefs;
+				const written = /* @__PURE__ */ new Set();
+				const list = [];
+				for (const entry of this.rawStoredAccounts()) {
+					const ref = entry.apiKeyEnv;
+					if (typeof ref !== "string" || ref === "") {
+						list.push({ ...entry });
+						continue;
+					}
+					if (removed.has(ref) || written.has(ref)) continue;
+					written.add(ref);
+					list.push(this.accountEntry(ref, entry));
+				}
+				for (const extra of this.addedAccounts) {
+					if (written.has(extra.ref)) continue;
+					written.add(extra.ref);
+					list.push(this.accountEntry(extra.ref, extra));
+				}
 				await this.scope.set("accounts", list);
-				const after = this.storedExtras();
-				return after.length === list.length && list.every((item, index) => after[index]?.ref === item.apiKeyEnv);
+				const after = this.rawStoredAccounts();
+				return after.length === list.length && list.every((item, index) => after[index]?.apiKeyEnv === item.apiKeyEnv);
+			}
+			/**
+			* One written account entry: the stored/added facts plus the label draft.
+			* `fallback` contributes the non-managed fields (a stored entry's literal
+			* `apiKey`, or any future field) so a rewrite never strips them.
+			*/
+			accountEntry(ref, fallback) {
+				const draft = this.labelDrafts.get(ref)?.trim();
+				const base = "ref" in fallback ? { label: fallback.label } : { ...fallback };
+				const storedLabel = base.label;
+				return {
+					...base,
+					label: draft !== void 0 && draft !== "" ? draft : typeof storedLabel === "string" && storedLabel !== "" ? storedLabel : ref,
+					apiKeyEnv: ref
+				};
 			}
 			/** The stored routing rules from the settings section (`modelAccountRules`). */
 			storedRules() {
@@ -1034,6 +1094,7 @@ window.__ModuleLoader__.load({
 				const stored = this.storedRules();
 				this.addedRules = this.addedRules.filter((added) => !stored.some((rule) => sameModels(added.models, rule.models) && added.account === rule.account));
 				for (const [id, snapshot] of [...this.removedRuleIds]) if (!stored.some((rule) => sameModels(snapshot.models, rule.models) && snapshot.account === rule.account)) this.removedRuleIds.delete(id);
+				if (this.rulesBeforeSave !== void 0 && ruleFingerprint(stored) === this.rulesBeforeSave) return;
 				this.ruleDrafts.clear();
 			}
 			/** The stored visible-model allowlist (`visibleModels`); empty = show all. */
@@ -1966,9 +2027,31 @@ window.__ModuleLoader__.load({
 		function toggleModelSelection(selected, modelId) {
 			return selected.includes(modelId) ? selected.filter((value) => value !== modelId) : [...selected, modelId];
 		}
+		/**
+		* Whether the catalog is trustworthy enough to call an unlisted selection
+		* "retired". FALSE while the first fetch is still in flight and after a
+		* failure, because the catalog is empty then and every selected id would look
+		* stale — which turns the one-click stale cleanup into a button that silently
+		* empties the allowlist. A successfully loaded but empty catalog is treated as
+		* untrustworthy too: an empty list is far more likely a Host problem than every
+		* model being retired at once, and the explicit "show all" entry covers the
+		* user who really wants to clear the list.
+		*/
+		function catalogIsReady(readiness) {
+			return readiness.catalogIds.length > 0 && !readiness.catalogFailed;
+		}
+		/**
+		* Selected ids the loaded catalog no longer carries, in selection order.
+		* Callers gate user-visible "stale" affordances on {@link catalogIsReady} —
+		* the list itself is informational.
+		*/
+		function staleModelIds(selected, readiness) {
+			const catalogIds = new Set(readiness.catalogIds);
+			return selected.filter((id) => !catalogIds.has(id));
+		}
 		//#endregion
 		//#region package.json
-		var version = "0.10.3";
+		var version = "0.10.5";
 		var repository = {
 			"type": "git",
 			"url": "git+https://github.com/Mars-Sea/dsh-commandcode-provider.git"
@@ -3190,8 +3273,12 @@ window.__ModuleLoader__.load({
 				if (key === "ruleModelCount") return t("visibleModelsCount", params);
 				return t(key, params);
 			};
-			const catalogIds = new Set(state.catalogModels.map((model) => model.id));
-			const staleIds = state.visibleModels.filter((id) => !catalogIds.has(id));
+			const readiness = {
+				catalogIds: state.catalogModels.map((model) => model.id),
+				catalogFailed: state.catalogFailed
+			};
+			const staleIds = staleModelIds(state.visibleModels, readiness);
+			const catalogReady = catalogIsReady(readiness);
 			return /* @__PURE__ */ (0, react_jsx_runtime.jsx)("div", {
 				className: "cc-card",
 				"aria-label": t("visibleModelsTitle"),
@@ -3205,11 +3292,11 @@ window.__ModuleLoader__.load({
 								children: t("visibleModelsTitle")
 							}), /* @__PURE__ */ (0, react_jsx_runtime.jsxs)("span", {
 								className: "cc-badges",
-								children: [staleIds.length > 0 ? /* @__PURE__ */ (0, react_jsx_runtime.jsx)("button", {
+								children: [catalogReady && staleIds.length > 0 ? /* @__PURE__ */ (0, react_jsx_runtime.jsx)("button", {
 									type: "button",
 									className: "cc-reset",
 									disabled,
-									onClick: () => onSelect(state.visibleModels.filter((id) => catalogIds.has(id))),
+									onClick: () => onSelect(state.visibleModels.filter((id) => !staleIds.includes(id))),
 									children: t("visibleModelsCleanStale", { count: staleIds.length })
 								}) : null, count > 0 ? /* @__PURE__ */ (0, react_jsx_runtime.jsx)("button", {
 									type: "button",
@@ -3228,7 +3315,7 @@ window.__ModuleLoader__.load({
 							className: "cc-invalid",
 							children: t("rulesCatalogFailed")
 						}) : null,
-						staleIds.length > 0 && !state.catalogFailed ? /* @__PURE__ */ (0, react_jsx_runtime.jsx)("p", {
+						staleIds.length > 0 && catalogReady ? /* @__PURE__ */ (0, react_jsx_runtime.jsx)("p", {
 							className: "cc-hint",
 							children: t("visibleModelsStaleHint", { count: staleIds.length })
 						}) : null,