Add desktop Agent support: ZCode (Z.ai)

[yujiezhang-ops]

Request

Add support for ZCode, Z.ai's agentic development environment. Split out of #96, which requested three Agents at once.

Confirmed with the reporter: this means Z.ai's official ZCode desktop application, not simonyos/Z-CODE (an unrelated community terminal assistant) and not zcodeapp.com (an unrelated iOS/macOS tool).

It belongs in the desktop registry, not the CLI catalogue

ZCode is an Electron desktop application, so it does not go in manifests/agents.lock.json alongside the CLI Agents. It belongs in internal/desktopapp/registry.go, the same category as ChatGPT Desktop and WorkBuddy.

That distinction decides the whole shape of the work. desktopapp entries carry their own inspect / install / open implementations (registry.go:29-34) rather than a package manager contract, and WorkBuddy is the closer precedent of the two — it has its own ConfigPath and ConfigAdapter (registry.go:54-56, writing .workbuddy/models.json over the openai protocol), whereas ChatGPT Desktop shares Codex's config instead of having one of its own.

Confirmed from Z.ai's install docs

Per the official install page, current version 3.6.5, with builds for:

• macOS — Apple Silicon and Intel, .dmg
• Windows — x64 and ARM64, installer
• Linux — x64 .AppImage

Two install-time notes that matter for a managed install path: macOS shows a "damaged and can't be opened" error until quarantine is cleared (xattr -dr com.apple.quarantine /Applications/ZCode.app), and some Linux distributions need fuse for the AppImage. Both are the kind of thing installWorkBuddy already deals with for a downloaded .app — see internal/desktopapp/workbuddy.go:309 (installWorkBuddyMacOS) for how a downloaded bundle is currently placed.

Platform coverage is wider than WorkBuddy's, which matters because OneAgent ships macOS and Windows artifacts.

The blocking unknown

Whether ZCode's provider settings live in a config file we can write. This decides if ZCode can be an auto entry or only a launcher.

The install page documents configuration exclusively through the in-app UI — Settings → General for proxy, terminal shell and tray behaviour — and points at a separate "Connect Models" page for provider setup. No on-disk config path, base URL field, or key storage location appears anywhere in that content. Sign-in offers "Connect Z.ai", "Connect BigModel", or "Use API Key", and whether that API key path accepts an arbitrary OpenAI-compatible base URL is not stated.

Without a writable config file and a custom base URL mechanism, OneAgent can detect and launch ZCode but cannot configure it — which is a materially weaker feature than what the other Agents get.

Someone needs to install it and check:

1. Where settings are persisted. Electron apps commonly use ~/Library/Application Support/<app>/ on macOS and %APPDATA%\<app>\ on Windows. Look for JSON.
2. Whether the "Use API Key" path accepts a custom base URL, or only Z.ai and BigModel endpoints.
3. Whether writing that file out-of-band is respected on next launch, or overwritten from an internal store. If the app owns the file exclusively, configuration support is off the table regardless of format.

Note the cheaper alternative that already works

If the underlying goal is using GLM models, that is available today without any new Agent. Z.ai documents endpoints per their devpack quick start:

• https://api.z.ai/api/anthropic — Anthropic Messages protocol
• https://api.z.ai/api/coding/paas/v4 — OpenAI Chat Completions

A user adds Z.ai as a custom Provider and points claude-code or opencode at it. Their keys are plan-specific, so a Coding Plan key will not work against other Z.AI APIs.

This is worth stating in the docs regardless of whether ZCode support lands, since it solves the model-access problem immediately. It does not substitute for ZCode support if the goal is the ZCode environment itself.

Scope if it proceeds

1. Definition entry in internal/desktopapp/registry.go with inspect / install / open.
2. Platform detection across three OSes and four architectures — broader than any existing desktop entry.
3. If a writable config is found: a ConfigAdapter, a reader in internal/config/discovery.go, a writer, and golden fixtures.
4. Icon with recorded rights in frontend/src/components/icons/asset-rights.json, plus NOTICE. Note that WorkBuddy renders OpenAI's Codex mark as its own icon #66/fix: give each desktop Agent its own mark, and grid the Provider/Profile cards #72 fixed a bug where every desktop Agent rendered OpenAI's mark; a new entry must resolve to its own mark or the documented fallback, and DesktopAppSection.test.tsx guards that.

Priority

P3, blocked on the configuration question. If the answer is "no writable config", downgrade to detect-and-launch only and decide separately whether that is worth shipping.

[yujiezhang-ops]

Split out of #96. Related: #101 (bytedance/trae-agent).

The blocking question here is not installation — Z.ai publishes builds for macOS, Windows and Linux, and internal/desktopapp/workbuddy.go is a working precedent for placing a downloaded bundle. It is whether ZCode's provider settings live in a file we can write. Z.ai's install docs describe configuration only through the in-app UI and name no on-disk path.

If the answer is no, this drops to detect-and-launch only, which is a materially weaker feature than the other Agents get and worth deciding on separately.

Also worth surfacing to anyone reading this for the GLM use case: Z.ai's endpoints work with claude-code and opencode today via a custom Provider, no new Agent required. Details in the issue body.