Repository navigation
Description
Summary
Buzz Desktop's manual "Add agent > Create agent" form shows every preset harness (Claude Code, Codex, Buzz Agent, Goose, Amp, Cursor, Devin) as unavailable — even when the corresponding CLI is installed and already in active use by other managed agents on the same machine.
Reproduction
- Install
claude/codex/etc. CLIs to a directory that is only added toPATHvia a login-shell rc file (e.g.~/.zshrc: export PATH="$HOME/.local/bin:$PATH"), not present in the OS/launchd default PATH. - Launch Buzz Desktop normally (Dock/Finder/LaunchServices — not from a terminal that already has the augmented PATH).
- Open "Add agent > Create agent" and look at the "Agent harness" dropdown.
- Every harness option is marked unavailable/CLI-missing, including ones that are demonstrably installed and working.
Environment
- Buzz Desktop 0.5.18, macOS 26.6.2 (25G83), arm64
claudeandcodexboth resolve fine from an interactive shell (~/.local/bin), and both are actively running as managed-agent worker pools on this same machine at the time of the repro — so the binaries are not actually missing.launchctl getenv PATHreturns empty on this machine, i.e. a GUI-launched process gets the OS's bare minimum default PATH, not the login-shell PATH that adds~/.local/bin.
Root cause (best guess, unconfirmed against source)
Same class of bug as #4628: Desktop's harness-availability check for the create-agent UI appears to run against Electron's bare launchd environment rather than a login-shell-resolved PATH (or a PATH augmented the way the already-working agent-worker spawn path is). That worker-spawn path clearly can find these binaries — agents configured via agent_command_override (e.g. pointing at a wrapper script under ~/.local/bin-adjacent paths) start and run fine. Only the create-agent form's dropdown detection appears to miss them.
Unlike #4628 (which is a runtime setup-payload parse failure after an agent is already configured with a custom command), this blocks agent creation entirely at the picker stage — before any config is saved — for every preset harness, not just custom ones. Filing separately since the user-facing surface and failure point differ, but flagging as likely related/same-root-cause.
Impact
Blocks creating any new managed agent through the manual "Create agent" flow, and equally blocks buzz agents draft-create (owner-reviewed draft flow) — that command opens the same prefilled create-agent form, so the draft path does not route around the broken dropdown either. On a machine where CLIs are installed via a login-shell PATH addition (a very common setup, e.g. pipx, nvm, ~/.local/bin installs), this makes the "Create agent" UI unusable regardless of whether the harness is actually present.
Suggested fix
Have the create-agent harness-detection check resolve commands the same way the already-working managed-agent spawn path does (inherit/resolve login-shell PATH, or explicitly search common user-local bin dirs like ~/.local/bin) instead of relying on Electron's bare launchd PATH.
Activity
jeremyd commentedon Aug 25, 2026
I encountered this problem too, it's intermittent. To fix it, I went to the "other" agent settings. The one you click your bottom left menu -> settings -> agents. Then you have a screen where you can "check again" the harnesses. That refreshed their status and it works again.
mariusbolik commentedon Aug 28, 2026
Same bug on Buzz Desktop 0.5.19, macOS, x86_64. CLIs are installed and work from a login shell:
claude→~/.local/bin/claude(2.1.241)codex→~/.local/bin/codex(0.150.1)grok→~/.local/bin/grok(1.0.5)launchctl getenv PATHis empty. A Dock-launchedbuzz-desktopgetsPATH=/usr/bin:/bin:/usr/sbin:/sbin. Managed agents can still spawn (Fizz was running~/.local/bin/grokwhile the UI said Grok Build was not installed).Settings → Agents → Check again recovers the catalog, matching @jeremyd's comment. Quitting Buzz wipes it again. After a restart Claude Code / Codex show as "CLI needed" and Grok Build drops off the installed list until that Settings probe runs.
This looks less like "login-shell PATH is never consulted" and more like the cheap/forced split from #6330:
discover_acp_providers(force: false)is cache-only (resolve_command_cached). Cache starts empty, so a miss is shown as not installed / CLI missing.~/Library/Application Support/Buzz/node-tools/bin, so they land ascli_missing(adapter present, vendor CLI not in cache).grokand no adapter, so a cache miss isnot_installed.force: true) does find them: login-shellcommand -vpluscommon_binary_paths()(which already includes~/.local/bin). That path only runs from Settings / onboarding (useAcpRuntimesQueryForcedwithforceOnMount), not on app launch.resolve_command_cachedreturning absent before any forced probe looks intentional (seecheap_discovery_reports_absent_before_any_forced_probe). The UI treats that cold miss as "not installed" instead of unknown, and nothing runs one background forced probe at startup. The catalog is in-memory only, so Check again does not survive quit.Suggested product fix (not "always force", which is what #6330 was avoiding):
common_binary_paths()(no login-shell spawn) for vendor CLIs likeclaude/codex/grok.Happy to test a patch on this machine.
fix(desktop): resolve bundled sidecar on cheap path and bound login-s…
fix(desktop): resolve bundled sidecar on cheap path and bound login-s…
fix(desktop): resolve bundled sidecar on cheap path and bound login-s…
fix(desktop): resolve bundled sidecar on cheap path and bound login-s…