[Bug] Claude Code agents ignore the model set in Buzz Desktop — model picker persists but nothing applies it at spawn

[bosoud]

Describe the bug

Setting a model for a Claude Code harness agent in Buzz Desktop (agent edit → model picker) persists the selection but never applies it: the spawned session runs on the user's global Claude Code default (~/.claude/settings.json / account default) instead. No error, no warning — the agent simply answers as a different model than the one configured.

Observed on Buzz Desktop 0.4.24 (macOS): a stock agent set to Sonnet reports claude-fable-5 in-session, across restarts.

Root cause

The model reaches spawned agents through runtime_metadata_env_vars (desktop/src-tauri/src/managed_agents/runtime.rs), which injects (model_env_var, effective_model) — but only when the runtime declares a model_env_var. The claude entry in KNOWN_ACP_RUNTIMES (desktop/src-tauri/src/managed_agents/discovery.rs) declares:

supports_acp_model_switching: false,
model_env_var: None,
provider_env_var: None,
provider_locked: true,

So for Claude Code there is no channel at all from the persisted model to the session: no env var, no ACP model switch. Goose (GOOSE_MODEL) and Buzz Agent (BUZZ_AGENT_MODEL) both have one. Meanwhile the model picker UI happily lists Anthropic models for the claude harness (discover_anthropic_models in commands/agent_models.rs) and persists the choice — a selection surface with no application path behind it.

Notably the readiness checker already knows the right key — readiness.rs maps Some("anthropic") => Some("ANTHROPIC_MODEL") — it's only the spawn-time runtime entry that lacks it.

Suggested fix

model_env_var: Some("ANTHROPIC_MODEL") on the claude runtime entry. The Claude Code CLI honors ANTHROPIC_MODEL as a session model override (verified locally: ANTHROPIC_MODEL=claude-sonnet-5 claude --print "…model id…" → claude-sonnet-5), and the ACP adapter's child claude process inherits the spawn env. provider_locked: true already keeps provider injection off, which is correct for this harness.

If that's adopted, ANTHROPIC_MODEL should probably also join DERIVED_PROVIDER_MODEL_ENV_KEYS (managed_agents/env_vars.rs) so a stale persisted copy can't shadow later UI edits — same treatment as GOOSE_MODEL/BUZZ_AGENT_MODEL.

Workaround

Until fixed, add ANTHROPIC_MODEL=<model-id> as a custom env var on the agent (edit agent → environment variables) and restart it.

To Reproduce

1. Create/edit a Claude Code harness agent in Buzz Desktop; set model to any non-default (e.g. Sonnet).
2. Restart the agent, ask it what model it runs on.
3. It reports the user's global Claude Code default, not the configured model.

Environment

• Buzz Desktop 0.4.24 (official Block-signed build), macOS (Intel), Darwin 25.5.0
• Claude Code harness via claude-agent-acp
• Repo state: block/buzz @ 06e3d82b

[skyerus]

Adding a second, closely related path we just traced on Buzz Desktop 0.4.24 (macOS, Apple Silicon, claude-agent-acp v0.61.0): the global default model (Desktop model picker → agents/global-agent-config.json → BUZZ_ACP_MODEL) does have an application channel for Claude Code — but it can silently fail at spawn and land on the same wrong-model outcome described here.

What we observed

global-agent-config.json had "model": "opus[1m]", and buzz-acp was launched with BUZZ_ACP_MODEL=opus[1m] (visible in the agent process env). Per crates/buzz-acp/src/pool.rs (~line 872), the harness resolves the desired model against the fresh session/new response via resolve_model_switch_method() (crates/buzz-acp/src/acp.rs) — an exact string match against the advertised configOptions/availableModels. At spawn it missed:

2026-07-24T08:43:38.691656Z  WARN pool::model: desired model opus[1m] not found in agent's available models — proceeding with agent default

…and the session fell back to the "agent default", i.e. whatever ~/.claude/settings.json happens to pin (in our case claude-fable-5[1m], churned by the user's ordinary Claude Code sessions). The agent then reports Fable 5 in-session — same symptom as this issue, different mechanism.

The suspicious part: running /Applications/Buzz.app/Contents/MacOS/buzz-acp models afterwards (warm) lists opus[1m] as a perfectly valid stable configOption value:

Models (stable configOptions):
  - default
  - opus[1m]
  - claude-fable-5[1m]
  - sonnet
  - haiku

So the spawn-time miss looks like a cold-start model-discovery race rather than a genuinely unsupported ID — this harness boots ~24 agents concurrently (agents=24 in the startup log), and the session/new response the validation ran against apparently didn't yet include the full model list. Possibly related to #2261 (cold-start model discovery returning empty for Codex).

Net effect: even where a model channel exists for Claude Code, one silent WARN turns the user's explicit selection into "whatever the user's last interactive Claude Code session set" — which makes the failure look nondeterministic to end users.

Two suggestions beyond the model_env_var: Some("ANTHROPIC_MODEL") fix proposed above (which we agree with):

1. Retry/defer the session/set_model validation when the advertised model list is empty or lacks the desired ID at spawn (it may simply not be populated yet), rather than falling back permanently on first miss.
2. Surface the fallback to the user (Desktop toast or agent status), not just a harness-log WARN — today the only way to notice is to ask the agent what model it's running.

Workaround we're using (complementary to the env-var one above): a project-scoped .claude/settings.json in the buzz-acp working directory pinning "model": "opus[1m]". The adapter loads settingSources: ["user", "project", "local"], and project beats user, so agent sessions get a stable model that interactive Claude Code sessions can't churn. Verified with a headless run from that cwd resolving to claude-opus-4-8[1m].

[Chessing234]

Fixed in #2701 — Claude runtime now injects ANTHROPIC_MODEL at spawn.