Auth probe for the `claude` runtime reads a different credential store than the ACP adapter, and disagrees in both directions

[artemtrofymenko]

Describe the bug

The desktop probes the claude runtime's auth with claude auth status (desktop/src-tauri/src/managed_agents/discovery.rs, auth_probe_args). That command consults the claude CLI's own credential store. The runtime Buzz actually spawns is claude-agent-acp, which carries its own claude.exe inside @anthropic-ai/claude-agent-sdk-* and reads ~/.claude/.credentials.json plus CLAUDE_CODE_OAUTH_TOKEN.

Because they consult different sources, the probe does not predict whether the runtime works — and it can be wrong in either direction. Both were observed on the same machine on the same day:

	claude auth status	Real ACP cycle against claude-agent-acp
morning	{"loggedIn": true, "authMethod": "claude.ai", "subscriptionType": "pro"}, exit 0	fails: Failed to authenticate: OAuth session expired and could not be refreshed
evening	{"loggedIn": false, "authMethod": "none"}, exit 1	works: stopReason: end_turn

Throughout, ~/.claude/.credentials.json stayed an empty husk — accessToken length 0, refreshToken length 0, expiresAt 0 — regardless of what the CLI reported. The runtime only started working once CLAUDE_CODE_OAUTH_TOKEN was set via claude setup-token, and at that point the CLI reports "not logged in".

The false-positive direction is the damaging one: the UI shows the runtime as authenticated, the agent starts, joins a channel, and then silently fails every turn.

Steps to reproduce

1. Install the Claude Code CLI and the ACP adapter: npm install -g @agentclientprotocol/claude-agent-acp.
2. Run claude auth status and note the result.
3. Drive the adapter directly over stdio: initialize → session/new → session/prompt.
4. Compare. On a machine where ~/.claude/.credentials.json is empty but the CLI's own store is populated, step 2 reports authenticated while step 3 fails with authentication_failed.

Expected behavior

The auth badge reflects whether the runtime Buzz will spawn can authenticate.

Version and platform

• Buzz version: 0.5.5 (packaged Windows release)
• @agentclientprotocol/claude-agent-acp: 0.65.0
• OS: Windows 11

Suggested fix

Probe the consumer, not a sibling: run the adapter's own initialize (optionally session/new) and treat a successful handshake as authenticated. That exercises the same credential resolution the real turn will use. A cheaper partial improvement would be to also accept CLAUDE_CODE_OAUTH_TOKEN being set as evidence, since today its presence is invisible to the probe.

[quietloom]

Ran into this while trialling Buzz Desktop (0.5.11) on Windows this week — confirms the report and adds one more failure mode on top of the two documented above.

Environment: Buzz Desktop 0.5.11, Windows 11, Claude Code harness ("Maker" agent).

Baseline, matching the report exactly: onboarding showed "Claude Code: READY" (the claude auth status probe succeeding), agent created cleanly, no key prompt. First real task tagged to the agent produced no response; the agent's own log file showed a JSON-RPC internal error, Failed to authenticate: OAuth session expired and could not be refreshed, retrying with backoff and failing identically on every retry.

Attempt 1 — fresh interactive re-login (claude auth login --claudeai, magic-link flow): the originally-queued task dead-lettered after 10 retries; a brand-new task tagged immediately afterward hit the identical auth error right away. Rules out "just needed a fresh login."

Attempt 2 — the suggested workaround, CLAUDE_CODE_OAUTH_TOKEN: set the env var directly on the agent's own config via the Desktop app's UI. Verified it actually landed correctly by reading managed-agents.json directly (not just trusting the UI). This did NOT reproduce the same auth error — instead the Desktop app dropped the agent into what looks like a distinct gating state: it published a "needs configuration" message into the channel instead of processing the queued task, rather than running it or repeating the OAuth-refresh error.

So on the Desktop app specifically, there appear to be at least three distinct checks in play, not two: the onboarding probe (claude auth status), the ACP adapter's own handshake (what this issue documents), and a third Desktop-app-side completeness check that the documented CLAUDE_CODE_OAUTH_TOKEN workaround doesn't seem to satisfy on its own. Happy to share the redacted managed-agents.json shape or log excerpts if useful — didn't want to paste raw logs here since they came from a personal setup.

[artemtrofymenko]

Thanks for the 0.5.11 report — the needs configuration state is the most useful detail added to this issue so far, and I think it collapses into the same probe rather than being a third credential store. Traced on 0.5.14 (every file cited below is byte-identical to 0.5.8, so the trace holds for both):

The nudge is this probe. ProbeOutcome::LoggedOut becomes Requirement::CliLogin in desktop/src-tauri/src/managed_agents/readiness/cli_login.rs, which is what makes an agent NotReady. For the claude runtime, discovery.rs declares required_normalized_fields: &[] alongside auth_probe_args: Some(&["claude", "auth", "status"]) — so that probe is the only auth requirement this runtime has. There is nothing else for readiness to consult.

The probe does not look at CLAUDE_CODE_OAUTH_TOKEN. On my machine the token is present in the inherited environment — the spawner only adds variables, it never calls env_clear — and claude auth status still returns {"loggedIn": false, "authMethod": "none"} with a non-zero exit. So the probe is red for anyone applying the workaround in this issue, by construction.

What differs is when readiness last ran. It is not continuous. agent_readiness() is called at discovery and on config change: commands/global_agent_config.rs computes old_ready / new_ready and feeds should_restart_on_config_change.

That would make the UI route self-defeating. Setting the token on the agent's own config is itself the event that re-evaluates readiness, which runs the probe, which is red — so applying the workaround triggers the check that then gates the agent. Setting the same variable in the OS environment never touches the agent record, so nothing re-evaluates, the previous Ready verdict stands, and the adapter still receives the token because child processes inherit it.

That matches your sequence: the OAuth error disappeared — the adapter did get the token — and a gate appeared in its place.

My data point, 0.5.14, Windows 11. Token set as a user-level environment variable; the agent's own env_vars empty (verified in managed-agents.json); agent card green with no nudge; claude auth status red. The agent answered a channel mention 23 seconds after it arrived earlier today, so the disagreement exists here too — it is simply not gating, plausibly because nothing has re-run readiness on that agent since before the token existed.

Two things that would confirm the mechanism on 0.5.11:

1. Set the variable in the OS environment instead of the agent config, restart the app, and see whether the agent runs without the nudge.
2. On a currently-working agent, edit any unrelated field. If the nudge appears without the auth state having changed, the trigger is the re-evaluation rather than the credential.

If that holds, the workaround in this issue is incomplete rather than wrong: it needs to say where to set the variable, because the obvious place is the one that arms the gate.

---

Edited to correct the version: my data point is 0.5.14, not 0.5.8 — the desktop auto-updated minutes before the run and I carried the old number over from an earlier session. That makes it newer than your 0.5.11 rather than older, which is the more useful comparison.

[chinglinwen]

This remains reproducible in the m4 deployment and is relevant to the current incident. Desktop readiness probes the sibling CLI with claude auth status (desktop/src-tauri/src/managed_agents/readiness/cli_login.rs), but the runtime actually used for turns is claude-agent-acp, spawned by crates/buzz-acp/src/acp.rs and backed by its own child-side credential resolution. A successful CLI probe therefore does not prove an ACP turn can authenticate; conversely, a stale probe can put the managed agent into setup mode even after credentials are refreshed. The practical mitigation observed here is a full Buzz/buzz-acp restart followed by a readiness retry, but the durable fix should probe the consumer path or surface the discrepancy explicitly.