nanobot vs OpenDuet

nanobot

nanobot runs on the owner's machine under the MIT licence, with no telemetry found in its source and memory kept as files the owner can read and restore. No per-action approval step was found, and the shell sandbox and workspace restriction are off by default. Five security advisories were published between March and September 2026, all with fixes.

OpenDuet

Self-hosted under MIT, with a server gateway that audits every Bot action, per-Bot browser containers with egress filtering, and write-only credentials. Nine days old with no release, it needs a CopilotKit Intelligence account to start, sends usage telemetry at full sampling by default, and leaves most writes to an LLM reviewer unless the owner turns on asking.

nanobot

1. Set tools.restrictToWorkspace to true and tools.exec.sandbox to bwrap or seatbelt before giving it real accounts. Both are off by default
2. Run 0.3.0 or later. Earlier versions carry the published SSRF flaw in web fetch (GHSA-vc5v-6vwm-wf9m)
3. Keep allowFrom narrow on every channel and never set ["*"] on Email, which has no pairing
4. Write secrets as ${VAR} references in ~/.nanobot/config.json. Plain values are stored in clear text
5. Use nanobot -m "..." for a one-shot run, and keep nanobot gateway running for channels, schedules and heartbeat

OpenDuet

1. Follow the README's Quick start (bun install, bash scripts/start.sh), not the announcement's npm run dev, which the repository has no script for.
2. Run bun openbot/scripts/setup-learning.ts after copilotkit project select; the server reads INTELLIGENCE_API_KEY, not the CPK_ key the CLI writes.
3. Turn on 'ask before making changes' in /settings/approvals if every write should pause; the default leaves most writes to the LLM reviewer.
4. To bring your own agent, register it as a remote-ag-ui Bot in agents.yaml; its tool calls still pass through the gateway's policy and audit.
5. Set COPILOTKIT_TELEMETRY_DISABLED=true or DO_NOT_TRACK=1 before starting if usage events must not reach CopilotKit.