OpenCode / Cursor / Kilo shown as "Built-in" but their CLIs are never installed — fails silently as a missing model picker

[Ukaykhingmarma28]

OpenCode, Cursor, and Kilo Code are presented as "Built-in" in the agents marketplace, but Atlas does not bundle their CLIs and offers no way to install them. When their binary is absent, the spawn fails, the error is swallowed, and the only user-visible symptom is a chat with no model picker at all — which reads as "I can't connect a model to this agent."

Reproduce

On a machine without the opencode, cursor-agent, or kilo CLIs on PATH:

1. Open Settings → Agents. All three show a "✓ Built-in" chip with the tooltip "This agent ships with Atlas" and no Install button.
2. Switch a chat tab to any of the three.
3. The tab binds, the composer renders — but the model picker never appears, and nothing indicates why.

Claude Code and Codex are unaffected: they launch via npx -y @agentclientprotocol/..., which self-installs the adapter.

Root cause

1. Bare-binary specs with no install path

The three specs shell out to binaries the user is expected to already have (crates/atlas-acp/src/registry.rs:121-170):

Agent	Command	Bootstraps itself?
Claude Code	npx -y @agentclientprotocol/claude-agent-acp	yes
Codex	npx -y @agentclientprotocol/codex-acp	yes
OpenCode	opencode acp	no
Cursor	cursor-agent acp	no
Kilo Code	kilo acp	no

2. "Built-in" is conflated with "installed"

BUILTIN_REGISTRY_IDS (crates/atlas-registry/src/store.rs:24) includes opencode, cursor, and kilo. Two consequences:

• agents-marketplace.tsx:356 renders the "✓ Built-in" chip and suppresses the Install button.
• RegistryStore::install() actively refuses them — "{id} is built into Atlas and cannot be installed from the registry" (store.rs:155).

So the UI asserts the agent is ready, provides no way to make it ready, and it isn't. The flag currently means "a first-party spec exists," but it is rendered to the user as "the runtime is present."

3. The failure surfaces as an empty model picker

Model lists for ACP agents only arrive in the session/new response — spawning is the only way to learn them (src/features/chat/lib/warm-acp-models.ts:5-8). So:

spawn ENOENT → no session → no `models` blob → acpAvailableModels empty
            → acp-models-cache empty → picker returns null

// src/features/chat/components/message-input.tsx:451
if (models.length === 0) return null;

The dropdown is not disabled or annotated — it is simply not rendered.

4. The correct diagnostic is written, then discarded

explain_spawn_failure (crates/atlas-acp/src/spawn.rs:210-260) already produces exactly the right message per agent:

the OpenCode CLI was not found. Install it from https://opencode.ai (then optionally run opencode auth login) and relaunch Atlas.

...plus equivalents for cursor-agent login and npm install -g @kilocode/cli. Every UI caller swallows it:

• src/features/chat/components/chat-panel.tsx:408 — console.warn("Agent session creation failed:", err)
• src/features/chat/components/chat-panel.tsx:566 — .catch(() => {}) on prewarm
• src/features/chat/components/chat-panel.tsx:124 — console.warn("agent restart failed:", err)
• src/features/chat/lib/warm-acp-models.ts:74 — bare catch {}

The hints land in the devtools console and nowhere else.

Suggested direction

Two independently useful fixes:

1. Make install state honest. Detect whether the runtime actually resolves (resolve_program_abs already does this) and surface it in RegistryEntryView as a separate field from builtin — e.g. runtime_available. The marketplace card can then show "Not installed" with the install command / help URL instead of "✓ Built-in". Optionally allow the marketplace to run the install for the three (npm i -g @kilocode/cli, the OpenCode/Cursor install scripts), the way node_setup already bootstraps Node.
2. Stop swallowing spawn errors. Propagate the explain_spawn_failure string into the chat surface — a banner or a disabled model picker with the reason — rather than console.warn. The message is already good; it just needs a UI destination.

Environment

• Atlas 0.3.0-x @ 1594e3a
• macOS (Darwin 24.6.0), Intel x86_64
• Node v24.16.0 via nvm, npx on PATH
• opencode, cursor-agent, kilo: not installed (no binary on PATH, no ~/.opencode, no ~/.cursor, no ~/.local/share/kilo/kilo.db)

Related

Distinct from #101 ("Opencode cannot change models"), which was the legacy models-blob deserialization drop fixed by model_sniff.rs. That path is fine — this issue is that the agent never spawns to produce a blob in the first place.

[Ukaykhingmarma28]

Fixed in #161.

The diagnosis in this issue held up. Atlas now does for these three what npx -y already does for Claude and Codex: RegistryStore::ensure_builtin downloads the official per-platform binary from the ACP registry manifest on first use and caches it, reusing the existing versioned-cache / sha256 / prune machinery. It hangs off the pre-flight agents_spawn already ran for registry externals, and it is never fatal — offline, unsupported platform, or no manifest all fall back to the bare PATH command, i.e. today's behaviour.

BUILTIN_REGISTRY_IDS stays as-is: acquisition is automatic, so the cards remain non-installable "Built-in" rather than growing an Install button.

Two things the fix surfaced that were not in the original write-up:

The silent stall. Cursor's archive is 77 MB, so first use is a real ~20 s wait. The composer's boot pill now reads "Setting up Cursor… 42%". The registry's progress callback fires once per HTTP chunk (~56k times for that download), so the events are throttled to whole-percent changes — an unthrottled version would have traded a silent stall for a janked UI.

Signing in was impossible, not just undocumented. These adapters advertise an auth method but ship no _meta.terminal-auth, so Atlas's terminal-auth runner had no command to run — and because the binary now lives in Atlas's app-data dir rather than on PATH, the adapter's own advice ("run agent login") could not be followed. Atlas now synthesises the login spec from the managed binary and offers a one-click "Sign in".

Worth recording for future work: Cursor rejects session/new, not the prompt. An unauthenticated agent dies at bind time and never reaches the turn-failure route that raises atlas:auth-required, so that path needed handling of its own.

Verified against the real binaries: Cursor cold-downloaded, extracted, and answered an ACP initialize with protocol v1 and the cursor_login auth method — reproducing this issue's repro steps in reverse, on a machine with no Cursor CLI.

The PR also adds an on/off switch for these three (Claude, Codex and Cersei are always on), since "built-in but optional" is now a real state.

Still open, tracked in the PR: OpenCode and Kilo will hang on the "Sign in" button — their auth login is an interactive TUI and the auth runner spawns with stdin closed. Cursor is unaffected. Keys can be set today via the CLI directly or the provider env vars those binaries read; the clean follow-up is injecting Atlas's existing BYOK keys into their env at spawn.