Common failure modes, in the order you're likely to encounter them.
First stop for any issue:
zeroclaw doctorRuns a series of checks and prints a summary. Most of what follows is the detailed version of what doctor flags.
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shOr 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-develFull 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:
- Use a prebuilt β
./install.sh --prebuiltskips the toolchain and downloads from GitHub Releases - Cross-compile on a bigger machine and copy the binary
- Serialise the build β
CARGO_BUILD_JOBS=1 cargo build --release --locked - Add swap (works for RAM, costs disk β check you have both)
The 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.htmlcargo 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 --forceOr just delete the directory and start over:
rm -rf ~/.zeroclaw
zeroclaw onboardHomebrew 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 onboardOr manually symlink once:
ln -s "$HOMEBREW_PREFIX/var/zeroclaw" ~/.zeroclawCheck journald / the platform log (see Logs & observability) for the actual error. Common causes:
- Invalid config β
zeroclaw config listto print resolved values,zeroclaw config schemato see the expected shape - Port conflict β another process on
42617; change[gateway] portor free the port - Missing secrets β encrypted secrets store can't decrypt because the key file is gone; restore from backup or re-run onboarding
systemctl --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 daemoncurl -sv http://localhost:42617/healthIf 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.
Two 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 slackIf 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 startMost often an auth failure β provider rotated the password or the app-password expired. Check:
journalctl --user -u zeroclaw -n 200 | grep -i imap- Ollama daemon not running:
systemctl status ollama(Linux),brew services list(macOS) - Wrong URL in config β from inside a container,
localhost:11434doesn't reach the host; usehost.docker.internalor the host's LAN IP - Firewall blocking port 11434 β rare locally, common on shared LANs
API 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:
- Approve inline when prompted
- Add the command to
[autonomy] allowed_commands - Raise autonomy to
Fullif you trust the context
See Security β Autonomy levels.
- Container image isn't pulled β
docker pull zeroclawlabs/tool-runner - Docker daemon not reachable from the ZeroClaw user β check
docker info - Tool needs a device that's not passed through β extend
allow_devices
Playwright 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 statusIf 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 listIf the paths differ between zeroclaw config list (as you) and the service (as its user), either:
- Set
ZEROCLAW_CONFIG_DIRin the service unit'sEnvironment= - Run the service as you (lingering-enabled user service)
- Copy/symlink the config to the path the service expects
Gather diagnostics and file an issue:
zeroclaw --version
zeroclaw doctor
zeroclaw channel doctor
journalctl --user -u zeroclaw --since "1 hour ago" > zeroclaw-log.txtSanitise zeroclaw-log.txt (redact channel tokens if any slipped through β they shouldn't) and attach it to the issue. See Contributing β Communication for where.