Skip to main content
NanoClaw is an open-source agent runtime that isolates every agent in its own Docker container. OneCLI is an open-source credential and policy layer for AI agents. Together, they give you the full stack: runtime isolation, credential isolation, and policy enforcement.

The full stack

LayerWhat it solvesProject
Runtime isolationEach agent gets its own container, filesystem, and process space. No ambient access to the host.NanoClaw
Credential isolationAgents never hold raw API keys. Credentials are injected at the proxy level per-request.OneCLI
Policy enforcementRules control what agents can access, which operations are allowed, and how often.OneCLI
NanoClaw solves the problem of agents escaping their sandbox. OneCLI solves the problem of agents misusing the access they’ve been given. You need both.

How it works

NanoClaw runs each agent in a Docker container. OneCLI runs as a sidecar (or shared service) that acts as the HTTP gateway for all agent traffic. When NanoClaw spawns an agent container, it configures the agent to route HTTP traffic through OneCLI’s gateway.
  1. NanoClaw creates a Docker container for the agent
  2. The container’s HTTP_PROXY / HTTPS_PROXY environment variables point to OneCLI’s gateway
  3. The agent makes normal HTTP requests. It doesn’t know OneCLI exists
  4. OneCLI checks rules (block/rate-limit), injects credentials, and forwards the request
  5. The response flows back to the agent

Setup

Prerequisites

1. Start OneCLI

docker run --pull always \
  -p 10254:10254 \
  -p 10255:10255 \
  -v onecli-data:/app/data \
  ghcr.io/onecli/onecli

2. Configure agents and credentials in OneCLI

You can do this through the dashboard at localhost:10254, or automate it with the OneCLI CLI:

3. Configure NanoClaw to route through OneCLI

When NanoClaw spawns agent containers, configure them to use OneCLI as their HTTP proxy. The agent containers need:
  • HTTP_PROXY and HTTPS_PROXY pointing to OneCLI’s gateway
  • The OneCLI CA certificate for HTTPS interception
  • A Proxy-Authorization header with the agent’s access token
If you’re using the Node.js SDK, applyContainerConfig() handles all of this automatically:
import { OneCLI } from "@onecli-sh/sdk";

const onecli = new OneCLI({
  url: "http://localhost:10254",
  apiKey: "oc_agent_access_token",
});

const args = ["run", "-i", "--rm", "--name", "my-nanoclaw-agent"];
await onecli.applyContainerConfig(args);

// args now has HTTPS_PROXY, CA certs, and volume mounts configured

One-line install (Cloud)

If you’re using OneCLI Cloud, the dashboard provides a one-line install command that clones NanoClaw, configures your .env with the correct Cloud URL and API key, installs dependencies, and sets up the CLI:
curl -fsSL https://app.onecli.sh/v1/install/nanoclaw | sh
After the script completes, follow the on-screen instructions to run the /setup wizard inside the NanoClaw directory.

Migrating from self-hosted to Cloud

If you’re already running NanoClaw with a self-hosted OneCLI instance and want to move to Cloud, use the migration script:
curl -fsSL https://app.onecli.sh/v1/migrate/nanoclaw | sh
The migration script:
  1. Exports secrets from your local OneCLI instance
  2. Updates your CLI config to point at OneCLI Cloud
  3. Finds all NanoClaw installations on your machine (via launchd, systemd, or common directories)
  4. Updates each NanoClaw .env with the Cloud URL and API key
  5. Restarts NanoClaw services so they route through Cloud
After migration, reconnect your OAuth app integrations (Gmail, GitHub, etc.) in the Cloud dashboard since OAuth tokens are not transferable between instances.

Per-agent policies

Since each NanoClaw agent gets its own OneCLI agent identity, you can set different rules per agent:
  • Your “email-agent” can read emails but not delete them
  • Your “code-agent” can access GitHub but not Slack
  • Your “research-agent” has read-only access to everything, rate-limited to 100 requests per hour
See Rules for the full details on setting up policies.