docs/book/src/ops/troubleshooting.md
Common failure modes, in the order you're likely to encounter them.
First stop for any issue:
zeroclaw doctor
Runs a series of checks and prints a summary. Most of what follows is the detailed version of what doctor flags.
cargo not foundcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Or pass --prebuilt to install.sh / setup.bat to skip Rust entirely.
Install the baseline toolchain for your distro, then re-run ./install.sh:
# Debian / Ubuntu
sudo apt install build-essential pkg-config
# Fedora / RHEL
sudo dnf group install development-tools && sudo dnf install pkg-config
# Arch
sudo pacman -S base-devel
Full per-distro list: Setup → Linux.
Compiling ZeroClaw from source needs ~2 GB RAM at peak. On a 512 MB Raspberry Pi, you will OOM.
Options:
./install.sh --prebuilt skips the toolchain and downloads from GitHub ReleasesCARGO_BUILD_JOBS=1 cargo build --release --lockedThe Matrix E2EE stack (matrix-sdk, ruma, vodozemac) and TLS/crypto native deps (aws-lc-sys, ring) are the main cost. Opt out if you don't need them:
cargo build --release --locked --no-default-features --features "default-lean"
Or check what's happening:
cargo check --timings
# report at target/cargo-timings/cargo-timing.html
zeroclaw: command not found after installcargo install puts binaries in ~/.cargo/bin/. Add to PATH:
export PATH="$HOME/.cargo/bin:$PATH"
Persist in your shell profile.
If an earlier install left ~/.zeroclaw/config.toml, re-run with --force:
zeroclaw onboard --force
Or just delete the directory and start over:
rm -rf ~/.zeroclaw
zeroclaw onboard
Homebrew installs prefer $HOMEBREW_PREFIX/var/zeroclaw/ (so brew services works). The wizard warns if it detects this — set ZEROCLAW_WORKSPACE to the Homebrew path before onboarding:
export ZEROCLAW_WORKSPACE="$HOMEBREW_PREFIX/var/zeroclaw"
zeroclaw onboard
Or manually symlink once:
ln -s "$HOMEBREW_PREFIX/var/zeroclaw" ~/.zeroclaw
Check journald / the platform log (see Logs & observability) for the actual error. Common causes:
zeroclaw config list to print resolved values, zeroclaw config schema to see the expected shape42617; change [gateway] port or free the portsystemctl --user status zeroclaw shows the last exit. If it's a config error, it stopped restarting (exit 2) and you need to fix the config. If it's a panic, the unit retries every 10 s.
Enable debug logging and catch the next failure:
zeroclaw service stop
RUST_LOG=zeroclaw=debug zeroclaw daemon
curl -sv http://localhost:42617/health
If connection refused: daemon isn't running, or it's bound to a different interface. Check [gateway] host / port in config.
If 403 / 401: pairing not completed or token expired. Run the pairing flow again.
terminated by other getUpdates requestTwo processes are polling the same bot token. Telegram only allows one poller at a time.
Fix: stop all but one zeroclaw daemon / zeroclaw channel start using that token.
Discord tokens expire if you regenerate them in the Developer Portal. Slack bot tokens don't expire but can be revoked. Check the bot is still installed in the target workspace/guild.
For either:
zeroclaw channel doctor discord
zeroclaw channel doctor slack
If you re-onboarded without keeping device keys, the homeserver sees a new device that hasn't been verified. Re-verify from another logged-in client, or reset the key store:
rm -rf ~/.zeroclaw/workspace/matrix-crypto
# re-run pairing flow on next channel start
Most often an auth failure — provider rotated the password or the app-password expired. Check:
journalctl --user -u zeroclaw -n 200 | grep -i imap
systemctl status ollama (Linux), brew services list (macOS)localhost:11434 doesn't reach the host; use host.docker.internal or the host's LAN IPAPI key invalid or expired. Regenerate at the provider's dashboard, update in [providers.models.<name>] api_key, restart the service.
If using OAuth (sk-ant-oat*), the OAuth token may have expired — OAuth-issued tokens are longer-lived but not infinite. Re-authenticate.
Check latency and error logs — the primary may be consistently timing out. If so, lower the retry count on the primary so it fails through faster, or fix whatever's making the primary flaky.
Expected behaviour at Supervised autonomy for unknown commands. Either:
[autonomy] allowed_commandsFull if you trust the contextSee Security → Autonomy levels.
docker pull zeroclawlabs/tool-runnerdocker infoallow_devicesPlaywright downloads Chromium (~150 MB) on first launch. Let it finish. If it keeps hanging, check disk space and proxy config.
zeroclaw service start
zeroclaw service status
If that succeeds interactively but the service dies in the background, it's almost always config or permissions — read the journal:
journalctl --user -u zeroclaw --since "5 minutes ago"
The service and CLI may resolve config differently if they run as different users or with different env vars. Force-print the path the daemon sees:
zeroclaw config list
If the paths differ between zeroclaw config list (as you) and the service (as its user), either:
ZEROCLAW_CONFIG_DIR in the service unit's Environment=Gather diagnostics and file an issue:
zeroclaw --version
zeroclaw doctor
zeroclaw channel doctor
journalctl --user -u zeroclaw --since "1 hour ago" > zeroclaw-log.txt
Sanitise zeroclaw-log.txt (redact channel tokens if any slipped through — they shouldn't) and attach it to the issue. See Contributing → Communication for where.