ZCode provider: drive zcode serve so the CLI owns credential exchange

[panudetjt]

Folded into #33685 — ZCode provider: bring-your-own Z.AI coding plan.

This thread is closed so the provider has one place to read. The design detail and the measurements are now in Appendix A of #33685, and the questions that need a maintainer answer are in that same discussion. The original text is kept below for history.

---

Follow-up to #33685 and PR #33684.

The problem

The ZCode provider drives zcode app-server --stdio. That protocol splits the CLI into a host and an agent: T3 Code plays the host, and the agent asks it for provider credentials before every account-model request. So the adapter has to read the CLI's encrypted credential store and mint a project access token through Z.AI's business endpoints itself. It is the only provider here that does either.

Every other provider integrates where the vendor binary owns credentials end to end: Kiro (kiro-cli acp --auth-method=cli), Antigravity and Claude (ACP / SDK authenticate), Codex (account/login/start), and OpenCode, which talks to opencode serve.

Proposal

Move the provider onto zcode serve, the CLI's own long-running server. Its host-side auth service performs the exchange in vendor code, so T3 Code never decrypts a provider credential store or reimplements a vendor endpoint chain.

What that costs:

• The transport changes from stdio NDJSON JSON-RPC to the CLI server's HTTP/WS surface: session create, streaming, approvals and MCP injection.
• The CLI owns install, upgrade and listening-port lifecycle. The OpenCode provider's server-owner/ledger code already models that and could be reused.
• Model enumeration and the entitlement ladder (provider/updateAccountConfig) need re-checking against what the server exposes.

Until then, the current adapter documents the credential read in docs/user/providers-zcode.md.

[panudetjt]

Implemented in #34713 upstream (stacked diff view: panudetjt#1, on top of #33684).

T3 now attaches to zcode serve — reads the status file plus ingress token, requests a host capability, starts the daemon detached only when none is healthy, streams the v4 conversation channel, and resolves interactions through resolveInteraction. The credential module and account-config push are gone; the daemon owns the exchange. Verified live against zcode 3.17.2 / provider v0.17.1: provider status, GLM model picker, streaming turn, AskUserQuestion, steering, interrupt, /compact, and resume after a T3 restart (fixed a reasoning-level bug on resume along the way).

[panudetjt]

Measured answer to the model-enumeration item in the cost list — the daemon exposes both the entitlement ladder and the picker, so T3 Code does not need to reconstruct them from setting.json or the catalog files, and provider/updateAccountConfig is not needed at all.

Read-only calls against a live daemon (zcode 3.17.2, provider CLI 0.17.1):

call	returns
oauth.getActiveProvider	"zai" — the login indicator (2 ms)
model-selection.getView	one provider account:zai-individual-coding-plan, models GLM-5.3 and GLM-5.3-Flash, reasoningLevel: [low, high, max], contextWindow: 1000000 (1 ms, 1958 B)
provider-settings.getView	all six account providers with accountState { availability, entitled, current, unavailableReason } plus executable (1-2 ms, 44 KB)

model-selection.getView matches what the branch's file-based enumeration produced, model for model, including reasoning levels.

Credential-free negative control. An isolated serve --supervisor instance seeded with the runtime catalog, setting.json, and provider_config.json, but no credentials.json, returns oauth.getActiveProvider → null, all six providers at availability: "unavailable", entitled: false, executable: false, unavailableReason: "not-connected", and model-selection.getView → providers: []. Nothing in that path touches the Z.AI credential store; the only local files a client needs are the daemon's own run/status.json and run/ingress-token.

Three traps worth recording before anyone builds on this:

1. usage-stats.getEntitlementSnapshot().authenticated is true even with no credentials ({"authenticated": true, "unavailableReason": "not_configured"}), so it is not a login signal. Use oauth.getActiveProvider !== null.
2. Logged out surfaces as unavailableReason: "not-connected", not "not-authenticated". accountState alone cannot separate "logged out" from "logged in, plan not connected", so pair it with oauth.getActiveProvider.
3. availability: "unknown" (account probe still running) makes models non-executable. An offline probe means an empty picker, where today's catalog enumeration would still list models — the badge has to distinguish "no models" from "not probed yet".

Cost. Warm daemon calls are 1-2 ms. The zcode doctor --json probe status.ts runs today is ~1.0 s (1.05 / 1.00 / 1.03 over three runs). provider-settings.onDidChange and model-selection.onDidChange are subscribable, so the badge and picker can refresh without polling.

Transport, for whoever reads the implementation. Frames are 1 byte kind + u32 id + u32 ack + u32 len, body is tagged/varint. A call header is [100, id, channel, method] with a single-element arg list; replies are 200 initialized, 201 result, 202 error, 203 rejected, 204 event. Dispatch is handler[cmd].apply(handler, args) on the service object, so the callable surface is exactly that object's methods — there is no introspection endpoint. The capability comes from POST /api/rpc-host-capability with the ingress token as Bearer, then travels as x-zcode-rpc-host-capability on ws://<host>:<port>/ws/host?token=….

Status: #34713 carried this and is closed unmerged; the branch is kept as tag panudetjt/t3code@zcode-ref-serve if anyone wants to read the code.

[panudetjt]

Folding this into #33685 so there is one thread to read: the product case, the credential-route comparison, and the measured zcode serve evidence now all live there (the transport detail is Appendix A), and the questions waiting on a maintainer are asked there too. Nothing was dropped — the original text stays in the body above for history.

Closing this thread rather than leaving two: a maintainer browsing Ideas should not have to work out which of two identically-named proposals is the actual ask.