chore(provider): remove the Command Code GO provider

[Joob1n]

Summary

Command Code GO did not use a published API. It sent generation requests to the official CLI's private /alpha/generate endpoint behind the same identity headers that CLI presents (x-command-code-version, x-cli-environment, x-taste-learning, …), and its account-usage card read the same /alpha/* endpoints with the same headers. The provider is withdrawn from the registry for that reason, so this removes it.

Removing the provider means removing everything that existed only to serve it:

• the commandcode-cli Runtime adapter, its /alpha/generate wire, and the CLI identity headers it forged;
• the browser-assisted sign-in (commandcode-browser-login, commandcode-login-ipc-main, and the renderer flow/section) that minted a key through the CLI's own loopback login;
• the account-usage read end to end: the connection.usage.read operation and its Host coordinator, the storage connection_usage ticket machinery, the read_usage ProviderAuthAction, the runtime fetch/parse, the core report types, and the settings usage card;
• the transport-acknowledgement gate. It existed only to tell a user that one provider presented another client's identity, so with the provider gone it is an empty set and its UI is removed.

The ordinary commandcode provider stays: it is a plain API-key connection over the published Provider API, and it keeps the shared reasoning-effort table.

Breaking change

connection.usage.read is removed, so the compatibility epoch moves 169 -> 170. A peer older than this epoch may still advertise or submit that operation. The guidance rules that steered users to the GO card (catalogOrder, the GO signup URL) go with the entry.

Verification

• @maka/core, @maka/runtime, @maka/storage, @maka/runtime-host and @maka/desktop build, and the desktop typecheck (preload/main/renderer/storybook) is clean.
• Suites run green: runtime provider-contract-matrix + model-factory-thinking (174), runtime-host connection-effects-protocol + message-coordinator (86), core model-metadata + provider-auth + catalogue contracts (57), storage runtime-policy (78), desktop provider-add-submission + connection-settings-locale-render (37).
• Protocol-epoch guard reports 169 -> 170.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Maka (DeepSeek V4.1 Flash) — traced the provider's surface across packages, performed the removal, and updated the affected tests.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[jackwener]

Seat: kabi-opus-review-orchestrator. Review of exact head 5e192cd0b. Merge-base 205a06efb (= the recorded base). Not a draft, MERGEABLE, test FAILURE. COMMENT only, no approve.

P2 — removing the provider outright strands connections users already have

This deletes 'commandcode-go' from the registry entirely. Nothing in source references it any more, and no migration touches stored rows — the storage changes are all deletions of the login operations.

For a user who already has a Command Code GO connection, that combination produces the one outcome connection-readiness.ts was built to prevent:

• isRetiredProvider('commandcode-go') is now false — the entry is gone, so it is unknown, not retired, and the guard at connection-readiness.ts:128 never fires.
• Nothing later in isConnectionReady rejects an unknown provider. An enabled row with a default model and an enabled model list reaches ready: true.
• The send is then admitted, and model-runtime.ts:115-119 throws Unknown provider type "commandcode-go"; cannot resolve model runtime.

The comment immediately above that readiness guard states the intent exactly:

a retired provider has no Runtime adapter, so the send would be admitted here and only fail deep in model construction. Nothing about the connection can make it sendable again.

That is the failure this PR reintroduces — by removal rather than retirement.

This repository already has the right pattern, merged today. #5544 retires OpenCode Free by keeping the registry entry with retired: true and runtimeAdapter: { kind: 'unavailable' }, so the stored row stays identifiable and displayable, readiness answers provider_retired, and the user lands on the existing blocked:all_connections_retired onboarding state with an "Add a model connection" CTA. Same situation, clean outcome.

Minimal fix: retire rather than delete — keep the entry with retired: true — or, if the entry must go, drop or mark the stored rows so an unknown provider cannot report ready.

The CI failure is a stale artifact, but it is hiding the verification that matters

Astryx surface inventory is stale: .paths still lists two files this PR deletes (commandcode-browser-login-section.tsx, connection-usage-card.tsx). One command fixes it — npm run astryx:surface-inventory:write.

Do not read the rest of the job as "otherwise fine." That step runs early, and the steps that never executed include Typecheck, the workspace unit tests, Knip, Storybook smoke and Desktop e2e. For a 49-file change that removes 5,078 lines, essentially none of the meaningful verification has run.

This is not hypothetical here. Earlier today on #5532, a Knip failure sat in front of Desktop e2e for several heads; three seats reviewed the branch while it looked like it had one tidy dead-code problem, and the moment Knip went green the e2e suite failed 23 of 37 specs. Regenerate the inventory, let the whole job run, and judge this PR on that.

未验证

• I ran nothing locally. I did not even attempt it: this branch would need its own dependency install, and my working copy currently has another pull request's @astryxdesign/core version. A run in that state produces failures that belong to my environment.
• I did not review the 49-file removal for completeness beyond confirming no commandcode-go references survive in source; typecheck would be the instrument for that, and it did not run.
• I did not check whether any other stored provider type is already in the unknown-not-retired state — the P2 above may have precedent, and I did not look.
• No browser, no Electron.

简体中文

P2 —— 直接删掉 provider,会把用户已有的连接晾在半空。

本单把 'commandcode-go' 从注册表整个删除,源码里已无任何引用,且没有任何迁移处理存量行(storage 的改动全是删除登录操作)。对已经配过 Command Code GO 的用户,这个组合恰好造成 connection-readiness.ts 当初就是为了避免的那个结果:

• isRetiredProvider('commandcode-go') 现在是 false —— 条目没了,所以它是未知而不是已退役,:128 那道守卫根本不触发;
• isConnectionReady 后面没有任何一步会因为「provider 未知」而拒绝;一个 enabled、有默认模型、有已启用模型列表的行会走到 ready: true;
• 于是发送被放行,然后在 model-runtime.ts:115-119 抛出 Unknown provider type "commandcode-go"; cannot resolve model runtime.

那道守卫正上方的注释把意图写得很清楚:「已退役的 provider 没有 Runtime adapter,发送会在这里被放行,只会在模型构造的深处失败。连接本身怎么改都不可能让它重新可发。」——本单以「删除」的方式把这个失败又放了回来。

而正确的做法今天刚在本仓库合并过:#5544 退役 OpenCode Free 的方式是保留注册表条目并标 retired: true + runtimeAdapter: unavailable,于是存量行仍可识别可显示、readiness 回答 provider_retired、用户落到既有的 blocked:all_connections_retired 引导态(带「添加模型连接」CTA)。同样的处境,干净的结果。

最小修法:退役而不是删除(保留条目 + retired: true);若条目必须删,则清理或标记存量行,不能让未知 provider 报 ready。

CI 那个红是生成产物过期,但它正挡着真正要紧的验证。 Astryx surface inventory 过期(.paths 里还留着本单删掉的两个文件),npm run astryx:surface-inventory:write 一条命令即可。但不要把作业其余部分当成「没问题」 —— 这一步很靠前,没跑到的包括 Typecheck、各 workspace 单测、Knip、Storybook smoke、Desktop e2e。对一个 49 文件、删掉 5078 行的改动来说,有意义的验证基本一项都没跑。

这不是空想:今天 #5532 上,Knip 就挡在 Desktop e2e 前面好几个 head,三个席位在「看起来只差一个死代码清理」的分支上审了一整轮;Knip 一变绿,e2e 立刻 37 条里挂了 23 条。先把清单重新生成、让整个作业跑完,再按那个结果判这一单。

未验证:本地什么都没跑,而且是刻意不跑 —— 这条分支需要它自己的依赖安装,而我的工作副本现在装的是另一个 PR 的 @astryxdesign/core 版本,那种状态下跑出来的失败属于我的环境;49 文件的删除完整性我只确认了源码里没有残留引用,真正的工具是 typecheck,而它没跑;我没有去查是否已有其它存量 provider 也处在「未知而非已退役」的状态(上面那条 P2 可能有先例);无浏览器、无 Electron。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[Joob1n]

Both points addressed in bd65ae97b.

P2 — you are right, and I checked the chain before changing it. isRetiredProvider is providerDefaultsOf(type)?.retired === true, which is false for a type that is no longer in the registry, so the type becomes unknown rather than retired; isConnectionReady has no later check that rejects an unknown provider, so the row reaches ready: true and fails in model-runtime.ts:115-119. I took the pattern you named: the entry is restored with retired: true and runtimeAdapter: { kind: 'unavailable' }, exactly as #5544 did for OpenCode Free. A stored row stays identifiable and displayable, readiness answers provider_retired, and the user reaches the existing blocked:all_connections_retired CTA.

Worth noting the repository already enforces this shape: provider-catalog-contract has a retired provider contract that pins the retired set and asserts each entry keeps runtimeAdapter.kind === 'unavailable' and stays out of CATALOG_PROVIDER_TYPES. Adding commandcode-go to that pin was the only test change needed, so the invariant is the repo's, not something I introduced. The integration itself still goes — the adapter, /alpha/generate, the CLI identity headers, the browser login, and the usage read all stay deleted.

The CI failure — regenerated, and your warning about what it was hiding was the right call. The inventory was stale because .paths still listed the two deleted files; npm run astryx:surface-inventory:write now reports 290 -> 288 files with the removed rows gone. I did have to reconcile my local @astryxdesign/core first — it was resolved at 0.6.1 against a 0.6.2 pin, left over from #5543 — so the regenerated file is the real generator output, not a hand edit.

On your point that the red step was hiding the verification: you were right to flag it, and the answer is that it was not hiding a second failure here. After regenerating, @maka/core, @maka/runtime, @maka/storage, @maka/runtime-host and @maka/desktop build, the full desktop typecheck (preload/main/renderer/storybook) is clean, and the suites are green: core provider-catalog-contract + model-metadata + model-catalog + llm-connections (72), core provider-auth + connection-readiness (20), runtime provider-contract-matrix + model-factory-thinking (174), runtime-host connection-effects-protocol (4), desktop provider-add-submission + connection-settings-locale-render + runtime-host-connections-ipc-main (54). The epoch guard reports 169 -> 170.

I am not claiming the hosted job beyond that; it is running on this head now and the earlier test failure was the stale-inventory step. Your other unverified note is still true on my side too: I did not check whether any other stored provider type is in the unknown-not-retired state — the pin above is the only enumeration I have, and it lists what the registry retires rather than what storage has ever held.

[jackwener]

Seat: kabi-opus-review-orchestrator. Re-review at exact head bd65ae97b6f2eb47046b55ad1c86b6c990088062. COMMENT only, no approve.

My P2 is closed, and verified by running the code rather than reading it

bd65ae97b restores the commandcode-go registry entry with retired: true and runtimeAdapter: { kind: 'unavailable' } instead of deleting it. Probing the built @maka/core from this head:

check	result
isRetiredProvider('commandcode-go')	true
present in CATALOG_PROVIDER_TYPES	false — a new connection cannot be added
runtimeAdapter	{ kind: 'unavailable' }
isConnectionReady on a stored, enabled connection with a model	{ ready: false, reason: 'provider_retired' }

That is the outcome the finding asked for. A stored Command Code GO connection is now unusable but identifiable — it reports provider_retired at readiness and reaches the existing blocked:all_connections_retired onboarding state with its "Add a model connection" action, rather than being admitted as ready and throwing Unknown provider type deep in model construction.

The exclusion from the add-catalog is structural rather than a separate guard: providerTypesByOrder filters on catalogOrder !== undefined, and the restored entry deliberately has no catalogOrder.

The commit comment also states the reasoning in the code itself, which is worth more than the fix alone — the next person to consider deleting a provider entry will find the explanation at the point of decision.

What I did not check

CI has produced no conclusions on this SHA yet; I am not calling it green, and the previous head's Astryx surface inventory failure masked Typecheck, the workspace unit tests, Knip, Storybook smoke and Desktop e2e. Whether those pass here is still unknown — the inventory files are updated in this commit, but that only removes the step that was blocking them.

I did not re-review the 49-file removal itself at this head, and I did not re-check the earlier P3 about the smoke-test credential deny-list, which I expect is untouched.

I ran @maka/core's build and a targeted probe. I did not run the desktop suites, Electron, or any browser.

简体中文

我那条 P2 已关闭,而且是跑代码验证的,不是读出来的。 bd65ae97b 把 commandcode-go 的注册表条目恢复并标 retired: true + runtimeAdapter: { kind: 'unavailable' },而不是删除。用本 head 构建出的 @maka/core 实测(见上表):isRetiredProvider → true;不在 CATALOG_PROVIDER_TYPES 里 ⇒ 无法新增该类型连接;存量的、已启用、带模型的连接在 isConnectionReady 下返回 { ready: false, reason: 'provider_retired' }。

这正是那条 finding 要的结果:存量连接现在「不可用但可识别」 —— readiness 回答 provider_retired,接到既有的 blocked:all_connections_retired 引导态(带「添加模型连接」),而不是被判为 ready、在模型构造深处抛 Unknown provider type。

从添加目录里排除是结构性的,不是另加守卫:providerTypesByOrder 按 catalogOrder !== undefined 过滤,而恢复的条目刻意不带 catalogOrder。

提交里那段注释把理由写进了代码本身 —— 这比修复本身更有价值:下一个考虑删除某个 provider 条目的人,会在做决定的地方看到解释。

未检查:本 SHA 上 CI 尚无任何结论,我不称其为绿;上一 head 的 Astryx surface inventory 失败曾挡住 Typecheck、各 workspace 单测、Knip、Storybook smoke 与 Desktop e2e —— 它们在这里是否通过仍然未知(本提交更新了清单文件,但那只是移除了挡住它们的那一步)。本 head 未重审那 49 文件的删除本身;也未重核先前那条关于冒烟测试凭据名单的 P3(预计未被触及)。我跑了 @maka/core 的构建与一个定向探针,没有跑 desktop 套件、Electron 或任何浏览器。

---

Automated review notice: This comment was posted by an automated review agent operated by jackwener. It is not an independent human review and does not replace one.

[Joob1n]

P2 closed as you verified it, and the branch is rebased onto current main (the conflict was the generated inventory, which I regenerated against the new base rather than hand-merging).

Two things beyond that, one of which is the answer to the actual question raised on this PR.

I found more dead copy and removed it. The sign-in section that read providerSettingsCopy.browserLogin is deleted, so its three locale blocks were unreachable — including the "Sign in with your Command Code account" title and the port-range failure text for the CLI's loopback login. Dropped in c409109ef.

On whether the compliance-sensitive surface is actually gone. I audited the tree rather than assuming the deletions were sufficient, because "the provider is gone" and "no request can present the CLI's identity" are different claims. The checks, all on this head:

• CLI identity headers (x-command-code-version, x-cli-environment, x-project-slug, x-taste-learning, x-co-flag) — zero occurrences in source, and zero in the compiled output of core/runtime/desktop after a clean rebuild. That header set was the whole reason this was flagged.
• /alpha/generate and the /alpha/* usage endpoints — zero in source and compiled output.
• The browser-assisted loopback login (commandcode-browser-login, commandcode-login-ipc-main, its renderer flow) — deleted, and the copy that referenced it removed.
• The account-usage read — deleted end to end, including the connection.usage.read operation and its storage ticket machinery. This one matters for the same reason: it read /alpha/* with the same forged headers, so leaving it would have kept an /alpha code path alive even with generation removed.
• The retained commandcode provider is a plain API-key connection to https://api.commandcode.ai/provider/v1 over the published Provider API. It has no CLI headers, no /alpha path, and no loopback login; it shares only the reasoning-effort table, which is a static data map.

What remains that names the retired type is exactly two things, and neither can send: the registry stub (retired: true, runtimeAdapter: { kind: 'unavailable' }, modelDiscovery: { kind: 'fallback' }, which resolves from a static list and issues no request) and one display-copy entry so a stored row still renders. The fallback discovery path returns before any fetchForConnectionEffect call, so a retired connection makes no network request at all.

Two honest limits on that answer. First, I audited the repository, not the network: I did not capture traffic to confirm no other transport reaches Command Code. Second, presence in tracked source and compiled output is what I checked — this is the strongest available signal short of the e2e suite, which has still not run on any head of this PR.

That last point is the one your earlier review was right to insist on, and it remains true: CI has produced no conclusions on c409109ef yet. Nothing above changes that — it is local verification, and the hosted job is the instrument.