Kodachi Claw - Anonymous AI Agent Runtime
Documentation Navigation
Navigate the documentation:
- Anonymity Features - What makes kodachi-claw invisible
- Internet Recovery - Auto-heal after MAC changes
- CLI Reference - All commands and flags
- Quick Start - Launch your first anonymous agent
File Information
| Property | Value |
|---|---|
| Binary Name | kodachi-claw |
| Version | 9.0.1 |
| File Size | 28.3MB |
| Author | theonlyhennygod |
| License | Proprietary - Kodachi OS |
| Category | AI & Intelligence |
| Description | Kodachi hardened AI runtime with embedded anonymity controls |
| JSON Data | View Raw JSON |
SHA256 Checksum
The Power of ZeroClaw. The Anonymity of Kodachi.
Get the power of ZeroClaw with full anonymity. Forged from ZeroClaw's ultra-lightweight Rust agent engine, kodachi-claw hides your AI agent inside the Tor network. Every API call, every model request, every channel message is routed through embedded Tor circuits. Your agent cannot be tracked, fingerprinted, or traced back to you.
While other AI agent runtimes run on the open internet, kodachi-claw wraps that same agent runtime with Kodachi's anonymity stack: embedded Tor circuits, identity randomization, OPSEC filtering, and network namespace isolation.
What is ZeroClaw?
ZeroClaw is an ultra-lightweight Rust AI agent runtime, the fastest and smallest autonomous assistant. It connects to 28+ AI providers, listens on 15+ communication channels (Telegram, Discord, Slack, Matrix, WhatsApp, Signal, Email, and more), executes tools, manages memory, and runs scheduled tasks, all from a single static binary.
kodachi-claw is forged from ZeroClaw and inspired by OpenClaw, the original Node.js personal AI assistant that pioneered multi-channel agent communication. kodachi-claw takes the ZeroClaw engine and wraps it with Kodachi's anonymity stack, making it the only AI agent runtime that operates entirely inside the Tor network.
Independent Runtime
kodachi-claw is not a KAICS sub-binary. It is an independent, standalone runtime that integrates Kodachi services (online-auth, ip-fetch, tor-switch, oniux) directly as in-process Rust libraries.
The Claw Family
Key Differentiator
All the claws give you an AI agent. Only kodachi-claw makes that agent invisible.
Standalone Download
kodachi-claw ships pre-installed with the Kodachi Terminal Server ISO, the Kodachi Desktop XFCE ISO, and the binary package. For separate deployment, it is also available as a standalone download below — no installer needed. Download both files to the same folder and run. The public key is embedded at compile time, so only the binary and its .sig file are required.
kodachi-claw Binary
StandaloneSingle static binary with embedded Tor runtime, identity randomization, and OPSEC filtering. Linux x86-64 only.
Installation
Download both files to the same folder and make the binary executable. No dependencies required — everything is statically linked. You can also download via browser and place both files in any directory you prefer (Desktop, Downloads, etc.).
mkdir -p ~/kodachi-claw && cd ~/kodachi-claw
wget https://www.kodachi.cloud/apps/os/install/kodachi-claw/kodachi-claw
wget https://www.kodachi.cloud/apps/os/install/kodachi-claw/kodachi-claw_v9.0.1.sig
chmod 755 kodachi-claw
# Option 2: curl (same result, different tool)
mkdir -p ~/kodachi-claw && cd ~/kodachi-claw
curl -LO https://www.kodachi.cloud/apps/os/install/kodachi-claw/kodachi-claw
curl -LO https://www.kodachi.cloud/apps/os/install/kodachi-claw/kodachi-claw_v9.0.1.sig
chmod 755 kodachi-claw
# Run (requires sudo for identity randomization)
sudo ./kodachi-claw onboard --interactive
Both Files Required
You must download both kodachi-claw (the binary) and kodachi-claw_v9.0.1.sig (the signature) and place them in the same folder. The binary verifies its own signature on startup — without the .sig file, kodachi-claw will refuse to run. You can use any directory you like: ~/Desktop, ~/Downloads, /opt/kodachi-claw, or anywhere else — just keep both files together.
f62a591c302a284dbfe11b1b32251e85d20401eedcbbbb95a1923d22a43ccc5f
Verification: The public key is embedded at compile time. Place the .sig file in the same directory as the binary — kodachi-claw verifies its own signature on startup.
ZeroClaw vs Kodachi Claw
kodachi-claw shares the ZeroClaw agent engine but adds a full anonymity stack, enhanced security, Kodachi service integration, and CLI enhancements. This table shows what kodachi-claw adds on top of ZeroClaw:
Anonymity Architecture
kodachi-claw wraps the ZeroClaw agent engine with a multi-layered anonymity stack:
┌─────────────────────────────────────────────────────────────┐
│ kodachi-claw binary │
│ │
│ ┌──────────┐ ┌────────────────────────────────────────┐ │
│ │ Agent │ │ Anonymity Stack │ │
│ │ Engine │ │ │ │
│ │ ─────────→│ │ ┌──────────┐ ┌───────────────────┐ │ │
│ │ Providers │ │ │ OPSEC │ │ Identity │ │ │
│ │ Channels │ │ │ Filter │ │ Randomization │ │ │
│ │ Tools │ │ │ (redact) │ │ MAC/Host/Timezone │ │ │
│ │ Memory │ │ └────┬─────┘ └───────────────────┘ │ │
│ │ Scheduler │ │ │ │ │
│ └──────────┘ │ ┌────▼───────────────────────────────┐│ │
│ │ │ Embedded Arti Tor Runtime ││ │
│ │ │ ┌─────┐┌─────┐┌─────┐ ... ×10 ││ │
│ │ │ │Circ1││Circ2││Circ3│ ││ │
│ │ │ └──┬──┘└──┬──┘└──┬──┘ ││ │
│ │ └───────┼──────┼──────┼───────────────┘│ │
│ └──────────┼──────┼──────┼────────────────┘ │
└─────────────────────────────┼──────┼──────┼──────────────────┘
▼ ▼ ▼
Tor Exit Nodes → AI Providers / Channels
Embedded Tor Runtime
kodachi-claw embeds the Arti Tor stack directly into the binary, no external Tor daemon needed.
| Mode | Flag | Description |
|---|---|---|
| Multi-Circuit (default) | --mode multi-circuit |
Pool of N Tor instances (default 10), load-balanced across requests |
| Isolated | --mode isolated |
Full network namespace via oniux, separate kernel network stack |
| Single | --mode single |
One Tor circuit for low-resource environments |
Circuit assignment strategies (--circuit-strategy):
| Strategy | Behavior |
|---|---|
| round-robin (default) | Each request goes to the next circuit in sequence |
| random | Random circuit per request |
| least-used | Route to the circuit with fewest active connections |
| sticky | Same tool/channel always uses the same circuit |
Identity Randomization
On startup, kodachi-claw randomizes your system fingerprint:
| Feature | Flag to Skip | Description |
|---|---|---|
| MAC address | --skip-mac |
Randomizes network interface MAC address |
| Hostname | --skip-hostname |
Sets a random hostname |
| Timezone | --skip-timezone |
Sets a random timezone |
| All three | --skip-identity |
Skip all identity randomization |
Use --restore-on-exit to restore original MAC, hostname, and timezone on shutdown.
Use --auto-recover-internet to automatically check and recover internet connectivity after each identity change (especially MAC randomization which cycles network interfaces) and on shutdown.
Verification & Leak Prevention
| Feature | Flag to Skip | Description |
|---|---|---|
| IP verification | --skip-ip-check |
Confirms traffic exits through Tor |
| DNS verification | --skip-dns-check |
Confirms DNS queries don't leak |
| OPSEC filter | - | Redacts outbound identity leaks from agent messages |
| Auth gate | --auth-mode auto\|required |
Kodachi online-auth integration (always runs, mode controls failure behavior) |
| Preflight checks | --skip-integrity-check, --skip-permission-check |
Integrity and permission verification before launch |
Tor Instance Management
| Setting | Flag | Default |
|---|---|---|
| Pool size | --tor-instances N |
10 |
| Instance policy | --instance-policy |
reuse (alternatives: new, mixed) |
| Instance prefix | --instance-prefix |
kodachi-claw-instance |
Namespace Isolation (oniux)
With --mode isolated, kodachi-claw uses oniux to create a Linux network namespace that forces ALL traffic through Tor at kernel level, no bypass is possible, even from misbehaving tools or libraries.
Quick Start
First-Time Setup
# 1. Run the interactive setup wizard (no sudo needed for onboard)
kodachi-claw onboard --interactive
# 2. Or quick setup with an API key
kodachi-claw onboard --api-key sk-... --provider openrouter
Launch Anonymous Agent
# Start interactive agent with full anonymity (10 Tor circuits)
sudo kodachi-claw agent
# Single query through Tor
sudo kodachi-claw agent --message "check my security posture"
# Start autonomous daemon (all channels + gateway + scheduler)
sudo kodachi-claw daemon
Control Anonymity Level
# Maximum isolation — kernel-level namespace via oniux
sudo kodachi-claw --mode isolated agent
# 20 Tor circuits for high-throughput agents
sudo kodachi-claw --tor-instances 20 daemon
# Sticky circuits — same tool always uses same exit node
sudo kodachi-claw --circuit-strategy sticky daemon
# Restore identity on exit
sudo kodachi-claw --restore-on-exit agent
# Skip all anonymity (direct connection — local testing only)
sudo kodachi-claw --skip-anonymity agent
Check Status
# Show Tor circuits, identity state, agent status
sudo kodachi-claw status
# JSON output for automation
sudo kodachi-claw --json-pretty status
# Show all commands and examples
kodachi-claw -e
Kodachi Service Integration
kodachi-claw integrates these Kodachi services directly as in-process Rust libraries (not external binary calls):
| Service | Integration |
|---|---|
| online-auth | Authentication gate, verifies Kodachi license before agent launch |
| ip-fetch | IP verification, confirms traffic exits through Tor |
| tor-switch | Tor instance management, creates and manages embedded Arti circuits |
| oniux | Namespace isolation, Linux network namespace for --mode isolated |
| cli-core | Shared CLI framework, consistent output formatting and JSON modes |
| auth-shared | Shared authentication, device ID and session management |
Optional integrations (enabled with --features kodachi-services):
| Service | Integration |
|---|---|
| dns-leak | DNS verification during preflight |
| permission-guard | Permission checks during preflight |
| integrity-check | Binary integrity verification |
| deps-checker | Dependency validation |
| logs-hook | Centralized logging |
| health-control | Internet connectivity recovery after identity changes (NetworkRecovery in-process) |
Claude Code CLI Provider — No API Key Needed
kodachi-claw includes a built-in Claude Code CLI provider that invokes the installed claude binary as a subprocess. No API key management needed. Claude Code handles authentication internally.
How It Works
- Lazy path detection - the CLI path is detected on first use (not at startup), so construction never fails
- Hardened search order - checks well-known paths first (
/usr/local/bin/claude,/usr/bin/claude), then~/.local/bin/claude, then falls back towhich claude - Subprocess invocation - runs
claude -p <prompt> --output-format text [--model <model>] - 120-second timeout - prevents hanging on long operations
- Secret scrubbing - redacts API keys from error messages
Usage
# Configure kodachi-claw to use Claude Code as the provider
kodachi-claw onboard --provider claude-code
# Or use it directly in agent mode (provider aliases: claude-code, claude, claude-cli)
kodachi-claw agent --provider claude-code --message "analyze my security posture"
# List all providers (claude-code shows as local — no API key required)
kodachi-claw providers list
Why This Matters
Most AI providers require API keys. On a fresh Kodachi installation, no API keys are configured. The Claude Code CLI provider bypasses this entirely. If Claude Code is installed, kodachi-claw can use it immediately. Combined with the anonymity stack, your agent talks to Claude through Tor with no API key exposure.
ai-gateway Integration — Safe Command Execution
kodachi-claw integrates with ai-gateway for policy-gated command execution across all Kodachi services. The gateway provides service discovery, risk classification, and approval workflows.
Discovery — Find Commands
# kodachi-claw can discover available commands through ai-gateway
ai-gateway search "check tor status" --limit 1 --json | jq '.data.results[0].invocation'
# Get full command specification
ai-gateway help tor-switch tor-status --json | jq '.data.needs_root,.data.offline_safe,.data.network_touching'
Safe Execution — Validate Then Run
# Step 1: Dry-run validates without executing
ai-gateway run tor-switch --command tor-status --dry-run --json
# Step 2: Execute passive command (no env var needed)
ai-gateway run tor-switch --command tor-status --json
# kodachi-claw integration path through ai-gateway
ai-gateway run kodachi-claw --command status --dry-run --json
ai-gateway run kodachi-claw --command status --json
Agent Identity and Capabilities
# Discover what kodachi-claw is allowed to do
ai-gateway capabilities --agent-id kodachi-claw \
--agent-token $KODACHI_AGENT_TOKEN_KODACHI_CLAW --json
Approval Workflow for Dangerous Operations
# Step 1: Human issues a time-limited approval ticket (10 minutes)
TICKET=$(ai-gateway approve issue health-control block-internet \
--agent-id kodachi-claw --ttl 600 --json | jq -r '.data.ticket')
# Step 2: kodachi-claw executes using identity + ticket
ai-gateway run health-control --command block-internet \
--agent-id kodachi-claw \
--agent-token $KODACHI_AGENT_TOKEN_KODACHI_CLAW \
--approval-ticket "$TICKET" --json
Why This Matters
Without ai-gateway, kodachi-claw executes commands directly. With ai-gateway, every command goes through a policy firewall with three-tier risk classification (Passive/Active/Dangerous), per-agent rate limiting, and human-in-the-loop approval for destructive operations. This adds a safety layer between the autonomous agent and real system operations.
For full ai-gateway workflows, see the ai-gateway Guide.
Scenario 1: First-Time Setup — Onboard and Launch Your Anonymous Agent
Get kodachi-claw running with full Tor anonymity in under 5 minutes.
Step 1: Initialize Workspace
# Interactive setup — walks you through provider selection, API keys, channels
kodachi-claw onboard --interactive
# Or quick setup with a single API key
kodachi-claw onboard --api-key sk-... --provider openrouter
Step 2: Launch the Agent Through Tor
# Start the agent — boots 10 Tor circuits, randomizes identity, verifies IP/DNS
sudo kodachi-claw agent
# Expected startup sequence:
# ✓ MAC address randomized (was 00:1A:2B:3C:4D:5E → 7A:3F:91:D2:E8:4C)
# ✓ Hostname randomized (was kodachi → xr7-phantom-node)
# ✓ Timezone randomized (was UTC → Pacific/Fiji)
# ✓ Tor pool started: 10 circuits active
# ✓ IP verification passed: exit node 185.xxx.xxx.xxx (Tor)
# ✓ DNS verification passed: no leaks detected
# ✓ Agent ready — all traffic routed through Tor
Step 3: Verify Anonymity
# Check full system status
sudo kodachi-claw status
# JSON output for scripting
sudo kodachi-claw --json-pretty status
Why this matters: Every API call, model request, and channel message goes through embedded Tor circuits. Your real IP, MAC, hostname, and timezone are never exposed.
Scenario 2: Maximum Isolation — Kernel-Level Namespace via Oniux
When standard Tor routing isn't enough, use network namespace isolation to guarantee no traffic bypasses Tor.
Step 1: Launch in Isolated Mode
# Full network namespace — separate kernel network stack
sudo kodachi-claw --mode isolated agent
# Expected output:
# ✓ Creating network namespace via oniux...
# ✓ Namespace active: all traffic forced through Tor at kernel level
# ✓ No bypass possible — even misbehaving libraries are contained
Step 2: Verify Namespace Isolation
# All traffic from the agent process is confined to the Tor namespace
sudo kodachi-claw --mode isolated --json-pretty status
Step 3: Run Autonomous Daemon in Isolation
# Long-running autonomous runtime with kernel-level Tor enforcement
sudo kodachi-claw --mode isolated daemon
Why this matters: In isolated mode, oniux creates a Linux network namespace that forces ALL traffic through Tor at the kernel level. Even if a tool or library tries to make a direct connection, it physically cannot — the kernel blocks it.
Scenario 3: High-Throughput Daemon — Multi-Circuit Load Balancing
Run an autonomous agent across multiple Tor circuits for parallel operations.
Step 1: Start Daemon with 20 Circuits
# 20 Tor circuits for high-throughput channel monitoring
sudo kodachi-claw --tor-instances 20 daemon
# Expected output:
# ✓ Tor pool started: 20 circuits active
# ✓ Gateway listening on 127.0.0.1:3000
# ✓ Channels active: Telegram, Discord, Matrix
# ✓ Scheduler running: 3 cron jobs
# ✓ Heartbeat: every 60s
Step 2: Use Sticky Circuits for Consistent Identity
# Same channel always uses the same exit node — prevents identity flickering
sudo kodachi-claw --tor-instances 20 --circuit-strategy sticky daemon
Step 3: Monitor Circuit Health
# Check all circuits and their status
sudo kodachi-claw --json-pretty status
# Run diagnostics
sudo kodachi-claw doctor
Why this matters: Each Tor circuit has a different exit IP. With round-robin or random strategy, your agent's apparent location changes per request. With sticky, each channel gets a consistent identity while remaining anonymous.
Scenario 4: Identity Management — Randomize, Verify, Restore
Control exactly what gets randomized and restore your original identity on exit.
Step 1: Selective Identity Randomization
# Randomize MAC only (skip hostname and timezone)
sudo kodachi-claw --skip-hostname --skip-timezone agent
# Randomize hostname only
sudo kodachi-claw --skip-mac --skip-timezone agent
# Skip all identity randomization (use current MAC/hostname/timezone)
sudo kodachi-claw --skip-identity agent
Step 2: Auto-Restore on Exit
# Randomize everything, but restore originals when the agent stops
sudo kodachi-claw --restore-on-exit agent
# Expected on shutdown:
# ✓ Restoring MAC address: 7A:3F:91:D2:E8:4C → 00:1A:2B:3C:4D:5E
# ✓ Restoring hostname: xr7-phantom-node → kodachi
# ✓ Restoring timezone: Pacific/Fiji → UTC
# ✓ Tor circuits closed
# ✓ Cleanup complete
Step 3: Skip Everything for Local Testing
# No Tor, no identity randomization — direct connection (testing only!)
sudo kodachi-claw --skip-all agent
Why this matters: --restore-on-exit ensures your system returns to its original state after the agent stops. This is critical for shared machines or when switching between anonymous and normal operations.
Scenario 5: Multi-Channel Anonymous Communication
Deploy your agent across multiple communication channels, all routed through Tor.
Step 1: Add Channels
# Add Telegram channel
kodachi-claw channel add --type telegram --token BOT_TOKEN --chat-id CHAT_ID
# Add Discord channel
kodachi-claw channel add --type discord --token BOT_TOKEN --channel-id CHANNEL_ID
# Add Matrix channel
kodachi-claw channel add --type matrix --homeserver https://matrix.org --token ACCESS_TOKEN --room-id ROOM_ID
Step 2: Start Daemon with All Channels
# Start autonomous daemon — listens on all configured channels through Tor
sudo kodachi-claw daemon
# Messages from Telegram, Discord, Matrix all arrive through Tor circuits
# Responses go back through Tor — channel providers never see your real IP
Step 3: Check Channel Health
# List active channels
kodachi-claw channel list
# Run channel diagnostics
kodachi-claw channel doctor
Why this matters: Every channel connection (Telegram API, Discord WebSocket, Matrix federation) goes through Tor. The channel providers see a Tor exit node, not your real IP address.
Scenario 6: Scheduled Tasks — Cron Jobs Through Tor
Schedule automated tasks that execute anonymously on a timer.
Step 1: Add Scheduled Tasks
# Run a security check every hour
kodachi-claw cron add --schedule "0 * * * *" --command "check security posture"
# Send a daily report to Telegram at 9am
kodachi-claw cron add --schedule "0 9 * * *" --command "send daily security report"
# Run DNS leak check every 30 minutes
kodachi-claw cron add-every --interval 30m --command "verify dns integrity"
Step 2: List and Manage Tasks
# List all scheduled tasks
kodachi-claw cron list
# Pause a task
kodachi-claw cron pause --id 1
# Remove a task
kodachi-claw cron remove --id 2
Step 3: Run Daemon with Scheduler
Why this matters: Scheduled tasks inherit the full anonymity stack — each cron execution goes through Tor with a fresh or reused circuit depending on your instance policy.
Scenario 7: Service Management — Install as System Service
Run kodachi-claw as a persistent system service that starts on boot.
Step 1: Install the Service
# Install as systemd service
sudo kodachi-claw service install
# Start the service
sudo kodachi-claw service start
# Check service status
sudo kodachi-claw service status
Step 2: Service Operates with Full Anonymity
# The service runs with the same anonymity stack:
# - Tor circuits are established on service start
# - Identity is randomized on service start
# - All channels and cron jobs run through Tor
# - Restore-on-exit triggers on service stop
Step 3: Manage the Service
# Stop the service
sudo kodachi-claw service stop
# Uninstall the service
sudo kodachi-claw service uninstall
Why this matters: As a system service, kodachi-claw starts automatically on boot with full anonymity. No manual intervention needed — your agent is always running and always anonymous.
Scenario 8: Diagnostics and Troubleshooting
Diagnose issues with Tor connectivity, channels, and system health.
Step 1: Run Full Diagnostics
# Check daemon, scheduler, and channel freshness
sudo kodachi-claw doctor
# Check AI provider model availability
sudo kodachi-claw doctor models
Step 2: Verbose Status Output
# Detailed status with all Tor circuits, identity state, agent config
sudo kodachi-claw -V status
# JSON output for parsing
sudo kodachi-claw --json-pretty status
Step 3: Test Connectivity Without Starting Agent
# Skip agent startup — just verify anonymity stack works
sudo kodachi-claw --skip-all status
# Test only Tor connectivity
sudo kodachi-claw agent --message "what is my IP?" --json
Why this matters: The doctor command checks all subsystems (Tor circuits, channel connections, scheduler jobs, provider availability) and reports issues before they become problems.
Scenario 9: Internet Recovery — Auto-Heal After Identity Changes
MAC address randomization cycles network interfaces down and up, which can break internet connectivity. kodachi-claw can automatically detect and recover from this.
Step 1: Enable Auto-Recovery
# Auto-recover internet after MAC changes and on shutdown
sudo kodachi-claw --auto-recover-internet --restore-on-exit agent
# Expected startup sequence:
# ✓ MAC address randomized (was 00:1A:2B:3C:4D:5E → 7A:3F:91:D2:E8:4C)
# ✓ Waiting 2s for interfaces to stabilize...
# ✓ Net check: IP ping OK, DNS resolve OK
# ✓ Internet connectivity verified after MAC change
# ✓ Hostname randomized
# ✓ Timezone randomized
# ✓ Tor pool started: 10 circuits active
Step 2: Standalone Recovery Command
# Check connectivity and recover if broken
sudo kodachi-claw recover-internet
# Force recovery (skip connectivity check, go straight to health-control)
sudo kodachi-claw recover-internet --force
# JSON output for automation
sudo kodachi-claw --json recover-internet
Step 3: Override Auto-Recovery
# Disable auto-recovery even if another flag enables it
sudo kodachi-claw --auto-recover-internet --skip-auto-recover-internet agent
How Recovery Works
- Net check: Pings
1.1.1.1(IP layer) and resolvesgoogle.com(DNS layer) with 6s timeouts - If connectivity OK: Continues normally
- If connectivity lost: Invokes health-control
NetworkRecoveryin-process (library call, not binary) - Health-control tries: ~10 recovery methods (interface restart, DHCP renew, DNS reset, etc.)
- Verification: Runs net check again to confirm recovery
- Non-fatal: All outcomes are logged but never abort the agent — connectivity loss is degraded, not fatal
Recovery Points
| Trigger | When |
|---|---|
| Post-MAC change | After network interface cycling during MAC randomization |
| Post-identity bootstrap | After all identity changes complete (belt-and-suspenders) |
| Shutdown | After identity restore, before Tor teardown |
| SIGINT/SIGTERM | Signal handler runs cleanup path including recovery |
| Manual | kodachi-claw recover-internet subcommand |
Why this matters: MAC randomization takes network interfaces down and up. On some hardware or network configurations, connectivity doesn't automatically restore. Auto-recovery ensures your agent always has internet access without manual intervention.
System Information
| Component | Version | License |
|---|---|---|
| kodachi-claw | 9.0.1 | Apache-2.0 |
| Arti (Tor) | 1.9.0 | MIT/Apache-2.0 |
| oniux | 0.8.1 | MIT/Apache-2.0 |
| Documentation | 9.0.1 | All Rights Reserved |
Related Documentation
- AI Overview — Full AI architecture, KAICS system, and service dependency map
- ai-cmd Scenarios — Natural language command execution and AI engine tiers
- ai-gateway CLI Reference — Command catalog, policy firewall, and safe execution
- kodachi-claw CLI Reference — Complete flag and subcommand reference
- ai-trainer Scenarios — Model training and snapshot management
- ai-learner Scenarios — Learning cycle and accuracy analysis
- ai-discovery Scenarios — Command pattern discovery and training data generation
- ai-monitor Scenarios — System monitoring and proactive suggestions
Examples
AI Agent
Start and interact with the AI agent
Interactive session with full anonymity
Expected Output: Tor bootstrapped, identity randomized, agent readyNote
Requires onboarding first: kodachi-claw onboard
Single message mode
Expected Output: Response through Tor-routed connectionSpecific provider/model
Expected Output: Agent session using Anthropic ClaudeLocal offline model
Expected Output: Agent runs with local model, Tor still active for toolsLow temperature for deterministic output
Expected Output: Agent runs with temperature 0.2Hardware peripheral attached
Expected Output: Agent with STM32 board attachedUse installed Claude Code CLI (no API key)
Expected Output: Agent uses local Claude Code CLI for inferenceNote
Requires claude CLI installed. No API key needed
Daemon & Gateway
Long-running services and webhook endpoints
Full daemon with all channels
Expected Output: Daemon running: all configured channels activeNote
Listens on all configured channels simultaneously
Custom gateway port
Expected Output: Gateway + channels + heartbeat + scheduler runningBind to all interfaces
Expected Output: Daemon bound to 0.0.0.0:9090Gateway-only (webhook/WebSocket)
Expected Output: Gateway accepting webhook requests on :9090Install as systemd service
Expected Output: Service installed with auto-restart on failureSetup & Onboarding
First-time configuration and channel management
Full wizard (9 steps)
Expected Output: Guided 9-step setup wizardNote
Run this first before using agent or daemon
Quick setup
Expected Output: Config created with OpenRouter providerQuick setup with memory backend
Expected Output: Config created with Anthropic + SQLite memoryQuick setup with Claude Code CLI (no API key)
Expected Output: Config created with claude-code providerNote
No API key needed -- Claude Code handles auth internally
Reconfigure channels only
Expected Output: Channel configuration updatedBind Telegram identity
Expected Output: Telegram user bound to allowlistStatus & Diagnostics
System status, health checks, and diagnostics
Full status including MAC, hostname, timezone, IP, auth
Expected Output: Complete system status with identity infoBasic status without security/identity info
Expected Output: Config and channel status onlyJSON status for automation
Expected Output: Pretty-printed JSON envelope with status dataRun health diagnostics
Expected Output: Diagnostic report for daemon/scheduler/channelsProbe model availability
Expected Output: Available models for the specified providerScheduled Tasks
Configure and manage cron-style scheduled tasks
List all scheduled tasks
Expected Output: Table of scheduled tasks with statusRun every 6 hours
Expected Output: Task added with cron scheduleWeekly with timezone
Expected Output: Task scheduled for Monday 9AM ETOne-shot at specific time
Expected Output: One-time task scheduledEvery 5 minutes
Expected Output: Interval task added (300s)One-shot after 30 minutes
Expected Output: One-time delayed task scheduledPause/resume tasks
Expected Output: Task paused/resumedModels & Providers
Manage AI model catalogs and providers
Refresh model catalog from default provider
Expected Output: Model catalog updatedForce refresh from specific provider
Expected Output: OpenAI model catalog force-refreshedList all 12+ supported AI providers
Expected Output: Provider table with active markerCheck cached model availability
Expected Output: Model availability from cacheChannel Management
Configure and manage communication channels
List configured channels
Expected Output: Channel status tableStart all configured channels
Expected Output: All channels listeningHealth check all channels
Expected Output: Channel health reportAdd Telegram channel
Expected Output: Telegram channel configuredRemove a channel
Expected Output: Discord channel removedBind Telegram user ID to allowlist
Expected Output: Telegram user ID boundAuthentication
Manage provider authentication profiles
OAuth login
Expected Output: Browser-based OAuth flow startedDevice code flow
Expected Output: Device code displayed for authorizationPaste API key
Expected Output: API key stored securelyInteractive token entry
Expected Output: Token stored in encrypted secret storeRefresh access token
Expected Output: Token refreshed successfullyList all auth profiles
Expected Output: Auth profile table with active markersShow active profile and token expiry
Expected Output: Profile status with expiration infoRemove auth profile
Expected Output: Auth profile removedSkills Management
Manage user-defined capabilities
List installed skills
Expected Output: Installed skills tableInstall from GitHub
Expected Output: Skill installed and registeredRemove installed skill
Expected Output: Skill removedIntegrations
Browse and manage service integrations
Show GitHub integration details
Expected Output: GitHub integration configuration and statusShow Jira integration details
Expected Output: Jira integration configuration and statusMigration
Import data from other agent runtimes
Preview migration without writing
Expected Output: Migration preview with changes listedImport from OpenClaw
Expected Output: Data imported from OpenClaw workspaceHardware & Peripherals
Discover and manage hardware devices
Enumerate USB devices and known boards
Expected Output: Detected hardware devicesIntrospect specific device
Expected Output: Device capabilities and firmware infoGet chip info
Expected Output: Chip specifications and pinoutList configured peripherals
Expected Output: Configured peripheral boardsAdd STM32 board
Expected Output: Peripheral added to configFlash firmware
Expected Output: Firmware flashed to deviceService Lifecycle
Install and manage as a system service
Install as systemd/launchd service
Expected Output: Service unit installedStart the service
Expected Output: Service startedStop the service
Expected Output: Service stoppedCheck service status
Expected Output: Service running/stopped statusUninstall the service
Expected Output: Service unit removedAnonymity & Tor Modes
Control Tor instances, circuits, and identity randomization
10 parallel circuits
Expected Output: 10 Arti instances bootstrapped, traffic distributed across circuitsNote
Default mode. Each tool/channel gets a different circuit
Namespace isolation via oniux
Expected Output: Namespace-isolated agent with embedded TorNote
Requires root or CAP_NET_ADMIN
Single circuit (low-resource)
Expected Output: Single Arti instance, minimal memory usageSticky circuit assignment
Expected Output: Sticky circuit assignment per tool/channelNote
Strategies: round-robin (default), random, least-used, sticky
Random assignment across 5 circuits
Expected Output: Random circuit selection per requestRestore identity on exit
Expected Output: Identity restored after session endsNote
Without this flag, spoofed identity persists after exit
Selective identity spoofing
Expected Output: Only timezone randomized, Tor still activeGateway access with required auth
Expected Output: Gateway mode with mandatory authenticationCheck and recover internet connectivity
Expected Output: Internet connectivity is working / Internet recovered successfullyNote
Invokes health-control recover-internet if connectivity is lost
Force recovery even if internet appears working
Expected Output: Internet recovered successfullyNote
Skips initial check, goes straight to health-control recovery
Check/recover with JSON output
Expected Output: {status: connected, recovery_needed: false, ...}Note
Returns JSON envelope with connectivity status and recovery details
Auto-recover internet after identity changes
Expected Output: Net check after MAC change, recovery on exitNote
Checks connectivity after MAC randomization and during shutdown
Skip flag overrides auto-recover
Expected Output: Agent runs without auto-recovery (skip wins)Note
--skip-auto-recover-internet takes precedence over --auto-recover-internet
Skip Controls
Disable specific startup phases for debugging or testing
No Tor, no identity changes
Expected Output: Agent runs without Tor, no identity changesNote
WARNING: No privacy protection. Local testing only
Skip all startup phases
Expected Output: Status with no anonymity bootstrapQuick status without Tor
Expected Output: Status report with auth check onlySkip verification checks
Expected Output: Tor starts but IP/DNS not verifiedSkip preflight checks
Expected Output: Agent starts without preflight verificationOutput & Automation
JSON output modes for scripting and CI/CD
Compact JSON for scripting
Expected Output: {"status":"success",...}Pretty-printed JSON
Expected Output: Formatted JSON with indentationHuman-annotated JSON
Expected Output: JSON with human-readable annotationsNote
Also: --json (compact), --json-pretty (indented)
Verbose logging
Expected Output: Debug-level log outputSuppress non-error output
Expected Output: Only error messages shownCustom network settings
Expected Output: 60s timeout, 5 retries, fresh instancesNote
Policies: reuse (default), new, mixed
AI Gateway Providers
Route requests through AI gateway proxies (Cloudflare, Vercel, custom OpenAI-compatible endpoints)
Use Cloudflare AI Gateway
Expected Output: Request routed through gateway.ai.cloudflare.com/v1 over TorNote
Set CLOUDFLARE_API_KEY env var or api_key in config. Supports all Cloudflare-hosted models
Use Vercel AI Gateway
Expected Output: Request routed through api.vercel.ai over TorNote
Set VERCEL_API_KEY env var or api_key in config
Any OpenAI-compatible gateway via custom URL
Expected Output: Request sent to your-gateway.example.com/v1/chat/completions over TorNote
Works with vLLM, LiteLLM, Azure OpenAI, any /v1/chat/completions endpoint
Anthropic-compatible proxy (corporate/self-hosted)
sudo kodachi-claw agent --provider "anthropic-custom:https://llm-proxy.corp.example.com" --message "review PR"
Note
For proxies that speak the Anthropic Messages API instead of OpenAI format
Groq ultra-fast inference gateway
Expected Output: Daemon running with Groq LPU inference, all channels activeNote
Set GROQ_API_KEY. Ultra-low latency for supported models
Together AI inference gateway
sudo kodachi-claw agent --provider together --model meta-llama/Llama-3-70b-chat-hf --message "analyze"
Note
Set TOGETHER_API_KEY. Supports 100+ open models
Fireworks AI inference gateway
sudo kodachi-claw agent --provider fireworks --model accounts/fireworks/models/llama-v3-70b-instruct --message "write tests"
Note
Set FIREWORKS_API_KEY. Optimized for fast open-model inference
Onboard with a custom AI gateway
Expected Output: Config created with custom gateway as default providerNote
The custom URL is stored in config.toml as default_provider
List all supported AI gateway providers
Expected Output: Table showing 30+ providers including Cloudflare, Vercel, Groq, Together, Fireworks, Mistral, xAI, and moreNote
Use custom: prefix for unlisted OpenAI-compatible gateways
CLI Reference
Global Flags
| Flag | Default | Description |
|---|---|---|
-v, --version |
- | Print version and exit |
-n, --info |
- | Show detailed program information |
-e, --examples |
- | Show comprehensive command examples |
--json |
- | Output as compact JSON |
--json-pretty |
- | Output as pretty-printed JSON |
--json-human |
- | Output as human-readable JSON |
--mode |
multi-circuit | Anonymity mode: multi-circuit, isolated, single |
--tor-instances |
10 | Tor pool size (ignored in single mode) |
--instance-policy |
reuse | Instance reuse policy: reuse, new, mixed |
--instance-prefix |
kodachi-claw-instance | Instance name prefix |
--circuit-strategy |
round-robin | Circuit assignment: round-robin, random, least-used, sticky |
--access-mode |
system | Access mode for execution path (gateway mode not yet implemented) |
--auth-mode |
auto | Authentication mode: auto (skip if unavailable), required (must succeed) |
--skip-mac |
false | Skip MAC randomization |
--skip-hostname |
false | Skip hostname randomization |
--skip-timezone |
false | Skip timezone randomization |
--skip-identity |
false | Skip all identity randomization |
--skip-tor |
false | Skip embedded Tor startup |
--skip-ip-check |
false | Skip IP/Tor verification |
--skip-dns-check |
false | Skip DNS verification |
--skip-anonymity |
false | Skip entire anonymity bootstrap |
--skip-integrity-check |
false | Skip integrity check during preflight |
--skip-permission-check |
false | Skip permission check during preflight |
--skip-all |
false | Skip all startup phases |
--restore-on-exit |
false | Restore MAC/hostname/timezone on shutdown |
--auto-recover-internet |
false | Auto-check and recover internet after identity changes and on exit |
--skip-auto-recover-internet |
false | Override and disable auto-recover even if --auto-recover-internet is set |
-V, --verbose |
false | Enable verbose logging |
-q, --quiet |
false | Suppress non-error output |
--no-color |
false | Disable colored output |
--timeout |
30 | Timeout in seconds for network operations |
--retry |
3 | Number of retries for network operations |
Subcommands
| Command | Description |
|---|---|
onboard |
Initialize workspace and configuration |
agent |
Start the AI agent loop |
gateway |
Start the gateway server (webhooks, websockets) |
daemon |
Start long-running autonomous runtime (gateway + channels + heartbeat + scheduler) |
service |
Manage OS service lifecycle (install, start, stop, status, uninstall) |
doctor |
Run diagnostics for daemon/scheduler/channel freshness |
status |
Show system status (full details) |
cron |
Configure and manage scheduled tasks |
models |
Manage provider model catalogs |
providers |
List supported AI providers |
channel |
Manage channels (Telegram, Discord, Slack, Matrix, etc.) |
integrations |
Browse 50+ integrations |
skills |
Manage skills (user-defined capabilities) |
migrate |
Migrate data from other agent runtimes |
auth |
Manage provider subscription authentication profiles |
hardware |
Discover and introspect USB hardware |
peripheral |
Manage hardware peripherals (STM32, RPi GPIO, etc.) |
recover-internet |
Check internet connectivity and recover if broken (invokes health-control) |