Agent troubleshooting
Start by proving the provider CLI works outside AgentDock, then compare that with what AgentDock itself resolves and reports.
Most agent-specific problems fall into one of a few buckets. Work through them in order before assuming something is broken in AgentDock itself.
1. Confirm the CLI works outside AgentDock
Run the provider's own version command directly in a terminal: claude --version, codex --version, or agy --version. If that fails, the problem is with the CLI installation or authentication, not AgentDock — see Install provider CLIs and Authentication.
2. Compare that with AgentDock's own resolution
Open Settings → Agents and use the Test action for the agent in question. It reports the exact path AgentDock resolved, the executable type, and the version it found — see CLI detection and diagnostics. A CLI that works in your terminal but fails this test usually means AgentDock is launching a different executable or a different environment than your shell does.
3. Check for provider-specific failure modes
- Claude Code — permission or tool-call failures usually show up as an interaction card; see Permissions.
- Codex — on Windows, a bare
codexonPATHcan resolve to an npm.cmdshim that Codex's SDK can't spawn directly; this is exactly why Codex uses a multi-tier resolver instead of a plainPATHsearch — see OpenAI Codex. - Antigravity — because permission and authentication prompts are detected by pattern-matching terminal output rather than a structured API, an unrecognized prompt string can stall a task instead of being classified correctly. The raw terminal drawer shows the literal text AgentDock is trying to match.
4. Set a custom executable path only if needed
If detection genuinely can't find a working install, override it in Settings → Agents with a specific path rather than fighting PATH resolution — see Agent configuration.