This guide covers common issues you may encounter when running NanoClaw and how to resolve them.Documentation Index
Fetch the complete documentation index at: https://docs.nanoclaw.dev/llms.txt
Use this file to discover all available pages before exploring further.
Quick status check
Run these commands to get a quick overview of system health:Agent not responding
Symptoms
Messages sent to the agent receive no response.Diagnosis
Check if containers are being spawned
Solutions
Trigger word not matching
Trigger word not matching
Container runtime not available
Container runtime not available
- macOS: Open Docker Desktop
- Linux:
sudo systemctl start docker
Queue at concurrency limit
Queue at concurrency limit
Container timeout
Symptoms
- Logs show
Container timeoutortimed out - Exit code 137 (SIGKILL) in container logs
- Messages are lost after timeout
Diagnosis
Solutions
Increase timeout for specific group
Increase timeout for specific group
containerConfig in the database:Check for infinite loops
Check for infinite loops
- Simplifying the prompt
- Adding constraints to the task
- Reviewing recent changes to
CLAUDE.md
Adjust idle timeout
Adjust idle timeout
src/config.ts and set:Service stops after SSH logout (Linux)
Symptoms
- NanoClaw works while SSH is connected but stops silently after disconnecting
systemctl --user status nanoclawshows inactive after reconnecting- No error logs or crash — the service simply disappears
systemctl --user enable nanoclawappears to succeed but the service still stops
Cause
By default, systemd setsLinger=no for users. When your last SSH session closes, systemd terminates all user-level processes — including the NanoClaw service. This is especially common on cloud VMs (EC2, GCP, Oracle Cloud).
Solution
The setup script automatically enables linger for non-root users. If you’re still experiencing this issue (e.g., you set up NanoClaw before this fix), run:loginctl enable-linger fails with a permission error, your system may require polkit authorization. Contact your system administrator or run the command with sudo.Known issues
Cursor rollback on error
The message cursor (lastAgentTimestamp) is now rolled back on container errors, provided no output was already sent to the user. If the agent fails after sending partial output, the cursor is not rolled back to prevent duplicate messages.
If you need to manually reset the cursor, update it in router_state:
IDLE_TIMEOUT and CONTAINER_TIMEOUT
The hard timeout is calculated asMath.max(configTimeout, IDLE_TIMEOUT + 30_000), ensuring a 30-second gap for graceful _close sentinel shutdown before the hard kill fires. With default settings (both 30 minutes), the hard timeout is 30 minutes 30 seconds.
If containers are consistently hitting the hard timeout, consider lowering IDLE_TIMEOUT in src/config.ts to a shorter value (e.g., 5 minutes) so idle containers exit more promptly.
Kubernetes image garbage collection deletes nanoclaw-agent image
Symptoms:Container exited with code 125: pull access denied for nanoclaw-agent — the container image disappears after a few hours, even though you just built it.
Cause: If your container runtime has Kubernetes enabled (Rancher Desktop enables it by default), the kubelet runs image garbage collection when disk usage exceeds 85%. NanoClaw containers are ephemeral (run and exit), so nanoclaw-agent:latest is never protected by a running container. The kubelet sees it as unused and deletes it — often overnight when no messages are being processed.
Fix: Disable Kubernetes if you don’t need it:
CONTAINER_IMAGE to an image stored in a registry that the kubelet won’t garbage-collect, or raise the kubelet’s GC thresholds.
Resume branches from stale tree position
Issue: When agent teams spawns subagent CLI processes, they write to the same session JSONL. On subsequentquery() resumes, the CLI reads the JSONL but may pick a stale branch tip, causing responses to land on a branch the host never receives.
Fix: Already fixed. The agent runner now passes resumeSessionAt with the last assistant message UUID to explicitly anchor each resume.
Container 401 errors
Symptoms
- Container logs show
401 Unauthorizedorauthentication_erroron API calls - Agent starts but fails immediately when trying to respond
- Errors recur every few hours even after restarting
Cause
Short-lived OAuth tokens copied from the system keychain or~/.claude/.credentials.json expire within hours. These tokens share the same sk-ant-oat01- prefix as long-lived tokens, so the mistake isn’t obvious. When they expire, every container launch fails with a 401.
Solution
- OneCLI Agent Vault (v1.2.35+)
- Credential Proxy (legacy)
claude setup-token:WhatsApp authentication issues
Symptoms
- Logs show “QR” or “authentication required”
- No messages are being received
- Connection repeatedly drops
Diagnosis
Solution
Re-authenticate with WhatsApp:Container mount issues
Symptoms
- Agent cannot access expected files or directories
- Logs show “Mount validated” or “Mount REJECTED”
- Permission errors in container logs
Diagnosis
Solutions
Add path to mount allowlist
Add path to mount allowlist
~/.config/nanoclaw/mount-allowlist.json:Reset mount allowlist to defaults
Reset mount allowlist to defaults
--force flag:--force, setup skips the mount allowlist if it already exists to preserve your customizations.Check for symlinks
Check for symlinks
Verify file permissions
Verify file permissions
Test mount manually
Test mount manually
IPC issues
Symptoms
- Messages sent via IPC don’t appear in the chat
- Tasks don’t get scheduled
- IPC files accumulate in
data/ipc/{group}/
Diagnosis
Solutions
Check IPC authorization
Check IPC authorization
Verify JSON format
Verify JSON format
Test IPC manually
Test IPC manually
Session artifact auto-pruning
NanoClaw automatically cleans up stale session artifacts on startup and then every 24 hours. This prevents disk usage from growing unbounded as sessions accumulate. Retention policy:| Artifact | Retention | Notes |
|---|---|---|
| Session JSONLs and tool results | 7 days | Active sessions (from DB) are never deleted |
| Debug logs | 3 days | Active sessions skipped |
| Todo files | 3 days | Active sessions skipped |
| Telemetry | 7 days | Active sessions skipped |
| Group logs | 7 days | — |
--dry-run to preview what would be deleted:
Stale session auto-recovery
NanoClaw automatically detects and recovers from stale or corrupt sessions. When a container fails because the session transcript file (.jsonl) is missing — due to a crash mid-write, manual deletion, or disk-full condition — NanoClaw clears the broken session ID and lets the existing backoff mechanism in the group queue retry with a fresh session.
Stale sessions are detected by matching the error output against known patterns (no conversation found, ENOENT on .jsonl files, or session not found). Only these specific signals trigger session clearing — transient errors (network, API) fall through to the normal retry path.
You can identify stale session recovery in logs by looking for:
Manual recovery
If auto-recovery doesn’t trigger (e.g., the error message doesn’t match the expected patterns), you can manually clear a stale session:Session branching issues
Symptoms
- Agent responses don’t appear in the conversation
- Session transcript shows multiple branches
- Concurrent CLI processes in session debug logs
Diagnosis
Solution
This issue was fixed by passingresumeSessionAt with the last assistant message UUID. If you’re still experiencing it, ensure you’re running the latest version of the agent runner.
Service management
Restart the service
View live logs
Stop the service
Start the service
Rebuild after code changes
Getting help
If you’re still experiencing issues:-
Ask Claude Code directly: Run
claudeand describe the problem. Claude can read logs, check database state, and diagnose issues. -
Run the debug skill:
claude→/debugfor guided troubleshooting. - Check the Discord: Join the community for help from other users.
-
Review recent changes: If the issue started after a customization, review what changed:
Related pages
- Security model - Authorization and isolation
- IPC system - Inter-process communication
- Container runtime - Container execution details