Troubleshooting
Run anymo doctor first. Each check has a stable id and a one-line fix; this page expands on the most common ones.
Doctor checks
| Check (id) | Status when… | What to do |
|---|---|---|
Rust (toolchain.rust) | FAIL if missing | Install the toolchain from rustup.rs. Required to build anything. |
Cargo (toolchain.cargo) | FAIL if missing | Ships with Rust; reinstall via rustup. |
Bun (toolchain.bun) | WARN if missing | Install from bun.sh. Only the desktop UI needs it; the headless CLI does not. |
Node (toolchain.node) | WARN if missing | Optional; install only if your workflow needs it. |
Desktop app host (app_server) | WARN if the UI bundle is missing | bun install then bun run dev:desktop. The kernel runs in-process inside the Tauri host; the optional headless host is anymo app-server. |
WebView runtime (webview) | WARN/SKIP | Windows: install the Evergreen WebView2 Runtime if the window won't open. Linux: install libwebkit2gtk-4.1-dev. macOS: built in. |
Model provider (provider) | WARN if none, FAIL if configured but invalid | Set ANYMO_PROVIDER_BASE_URL and ANYMO_PROVIDER_MODEL. The offline mock demo needs no provider. |
Endpoint (endpoint.N) | WARN if unreachable, SKIP if not probed | Start your local model server (for example ollama serve) or correct the base URL. Use doctor --no-probe to skip network checks. |
Browser bridge (browser_bridge) | usually OK | Built-in web.fetch / web.extract are always available. For full browser control, see Browser automation. |
Plugin trust (plugin_trust) | OK by default | Command-hook execution is disabled by default. Trust each plugin explicitly before enabling command hooks. |
Workspace (workspace) | FAIL if not writable, SKIP if absent | Run anymo setup to create it, or pass a writable --workspace <dir>. |
Key storage (key_storage) | WARN on the CLI; OK when the desktop seals a key | The headless CLI never persists a key; re-export ANYMO_PROVIDER_API_KEY per session. Desktop keys are sealed at rest in the OS keychain. |
Eval suite (evals) | SKIP if no report | cargo run -p anymo-evals -- run --all. |
OS bundle (os.N) | SKIP (informational) | Per-OS packaging notes; see the WebView row above. |
Common problems
doctor exits non-zero
There is a blocking FAIL, almost always a missing Rust toolchain or a non-writable workspace. The exact item and fix are printed in the report. Warnings alone never fail doctor unless you pass --strict.
The desktop window doesn't open
The WebView runtime is missing. Install WebView2 (Windows) or WebKitGTK (Linux). Build the UI first with bun install && bun run dev:desktop.
A run is stuck "awaiting approval"
That is the approval system working: in manual mode every tool call asks, and in auto mode high- and critical-risk tools (shell, browser, desktop control, MCP) still ask. Respond from the desktop Approvals surface, or against an app-server:
anymo approve --websocket <addr> --token <token> --approval-id <id>--decision approve|deny and --reason "..." are optional; the default decision is approve. In plan mode, side-effect tools are denied by design: the run can only read and propose.
goal pause or goal clear doesn't stop the run immediately
Pause and clear mark the goal store; the driving loop honors the mark after the current turn finishes and is evaluated. This is intentional: a turn is never killed halfway. goal resume starts a fresh driving session: counters reset, the condition is kept.
A skill doesn't appear as a slash command
Only enabled skills appear in the composer palette and are offered to runs via skill.invoke. Check the skill's enabled flag in the desktop Skills view, and confirm the skill exists:
anymo skill list --workspace <dir>Skill names in slash commands must match exactly (/<skill-name>).
An automation never fires
Automations only run while a host is alive: the desktop app or anymo app-server. If the machine was off or no host was running when a schedule came due, the missed run is skipped on purpose (no catch-up storms); the next due time fires normally. Check the automation is not paused in the desktop Automations view.
A connector won't finish OAuth
Connector sign-in opens your system browser and listens on a loopback callback. If the browser window never appears, check that a default browser is configured; if the callback times out, retry from the Plugins view. Tokens are sealed at rest, never appear in config files, and removing a connector removes its token.
The model endpoint keeps failing mid-run
Configure a fallback chain so a retryable failure on the primary endpoint switches to the next candidate instead of failing the run:
anymo run --provider http --goal "..." \
--fallback http://localhost:1234/v1,llama3.1Or via the environment: ANYMO_PROVIDER_FALLBACK_BASE_URL, ANYMO_PROVIDER_FALLBACK_MODEL, ANYMO_PROVIDER_FALLBACK_API_KEY. Each switch is recorded as a durable provider.fallback event in the run log.
Environment variables don't take effect on Windows
export is POSIX-shell syntax. In PowerShell use:
$env:ANYMO_PROVIDER_BASE_URL = "http://localhost:11434/v1"and run the CLI from the same PowerShell session.
Build errors mentioning a missing config field
This means a stale build artifact from another branch or git worktree is being linked. Force a clean rebuild of the protocol and its dependents:
cargo clean
cargo build --workspace --exclude anymo-desktopA test executable "requires elevation" on Windows
Windows UAC treats executables whose names contain setup or install as installers. Anymo's tests avoid those names (the setup tests live in tests/first_run.rs). If you add a test file, keep those words out of its name.
anymo setup says "completed" but I don't see output
The offline mock demo writes <workspace>/reports/headless-smoke.md and records events in <workspace>/.anymo/events.db. Both live inside the demo workspace (./anymo-demo by default), which is gitignored.