Desktop: transient "agent not installed" false negative that self-heals after visiting Settings → Agents (stale availability cache)

[michaelneale]

Summary

Buzz Desktop intermittently reports an agent as "not installed" (agent unavailable / CLI missing) when the agent's runtime is installed and previously working. The workaround is oddly reliable:

1. See the "agent not installed" state.
2. Open Settings → Agents — the agent/runtime shows as installed there.
3. Navigate back to where the warning appeared — it now works, with no reinstall or restart.

The fact that merely visiting the Agents settings page repairs the state strongly suggests a stale-cache problem rather than a real availability problem.

Difference from existing issues

• Create-agent harness dropdown shows every option unavailable when CLI is only on login-shell PATH, not GUI PATH #6662 / Windows: installed Codex/Claude ACP runtimes are reported as CLI missing #6869 / Desktop: remote-backend agents are gated on the local PATH — readiness probe and provider spawn see different environments #4350 are about runtimes that are never detected (GUI vs login-shell PATH, Windows alias discovery). This issue is transient: the runtime is detected fine after the settings page runs discovery, and was detected fine before.
• fix: make managed agent initialization recoverable #6855 is about ACP initialization timeouts/retries, not the availability badge.

Likely mechanism (from source, unconfirmed)

desktop/src-tauri/src/managed_agents/discovery.rs:

• resolve_command() memoizes command resolution in a process-lifetime resolve_cache().
• Adapter availability is memoized in adapter_availability_cache() ("Phase-2 badge fallback"). Per its own comment, it "is warmed by discover_acp_runtimes … and is invalidated by clear_resolve_cache (called on every Doctor install and every discover_acp_providers call)".

So any surface that renders availability from these caches while they are cold or stale (e.g. after app start, before a discovery pass; or after the environment/PATH state changed) can show "not installed". Opening Settings → Agents triggers discover_acp_providers, which calls clear_resolve_cache() → re-probes → repairs the badge — matching the observed "go to settings, come back, it works" behavior exactly.

Note adapter_availability_cached() deliberately returns None when cold to avoid fabricating an AdapterMissing badge — but the negative-result path of resolve_command (a miss is not cached, but callers that snapshot a miss into UI state may persist it) and whatever surface produces the user-facing "not installed" copy (runtimeAvailabilityWarning.ts, config-nudge-attachment.tsx cli_login availability states) may still render a stale negative until discovery runs.

Suggested direction

• Identify which surface shows the stale "not installed" and make it re-run (or await) discovery instead of trusting a cold/stale snapshot.
• Alternatively, treat "unknown/not yet probed" as a distinct state from "not installed" everywhere, the way adapter_availability_cached() already does — never render a hard "not installed" from unprobed state.

Environment

Reported by MicBlock on Buzz Desktop (macOS). Repro is intermittent; the settings-visit workaround has been consistent.

Originating Buzz channel: 1f042340-7334-4ca7-83fc-e98e5613ba92