nanobot

nanobot runs every tool as the operating-system user who launched it. It does strip API keys and other variables from the shell tool's environment, which is a real narrowing, but in the default configuration the file and shell tools can read and write anywhere in the user's home directory, including SSH keys, cloud credential files and nanobot's own config.json with its provider keys and chat-bot tokens. Because file tools are unrestricted by default, the agent can also rewrite its own config.json (for example widening who may message it or re-enabling self-configuration), even though the built-in self-configuration tool deliberately blocks those fields. A hijacked agent therefore holds roughly the user's whole account.

There is no human approval step for any tool call. Shell commands, file writes and deletes, outbound chat messages with file attachments, scheduled jobs and MCP tool calls all execute as soon as the model requests them. The WebUI's 'restricted' versus 'full access' mode changes path checks, not approval. Mistakes or hijacked actions such as deleting files or messaging third parties happen with no human in the loop and largely cannot be undone.

Tool input validation is uneven. The web fetch tool is well built: it blocks private, loopback and cloud-metadata addresses and re-checks every redirect. The file tools resolve symlinks and enforce workspace containment, and the shell tool has a deny-list and internal-URL check, but both of those only run when workspace restriction is turned on, and it is off by default. In the shipped configuration the shell tool takes arbitrary command strings with no filtering at all, and write, shell and network tools are all enabled.

By default shell commands run directly on the host as the user, with no isolation. nanobot ships an optional bubblewrap (Linux) or Seatbelt (macOS) wrapper that limits filesystem writes to the workspace and hides the config directory, and the Docker image includes bubblewrap, but it is off unless the operator sets tools.exec.sandbox. Even when enabled, the sandbox leaves network access open, does not cover CLI apps or MCP servers, and on Windows silently runs unsandboxed with only a log warning. The criterion is credited for the opt-in sandbox, capped because it is off by default.

nanobot reads lots of content its owner did not write: web pages and search results, inbound email and chat messages, files, MCP tool results and other sessions' history. Web results and session history are wrapped with an 'untrusted data' banner and the system prompt asks the model not to follow embedded instructions, but nothing in code limits what a hijacked agent can then do. In the same session it can read the config file holding API keys, send data out through web requests, shell commands or chat messages, and run destructive commands, all without approval. Inbound chat channels do deny unknown senders by default and use operator-approved pairing, which keeps strangers from instructing the agent directly.

Long-term memory (MEMORY.md), the persona files SOUL.md and USER.md, the project AGENTS.md and any 'always' workspace skills are injected into the system prompt on every turn. The model can write all of them with ordinary file tools, and a periodic 'Dream' job automatically consolidates conversation history into memory, so an injected instruction can persist and fire in later sessions. Memory is one store per workspace, shared across every channel and chat. There is a useful safety net: SOUL.md, USER.md and MEMORY.md are versioned in a local git store with /dream-log and /dream-restore, but AGENTS.md and skills are not.

nanobot loads several kinds of third-party code. Agent Plugins are handled well: enabling one binds to a content fingerprint and any change disables it. Everything else is weaker. Python packages that declare a 'nanobot.tools' entry point are loaded automatically into the agent's own process, MCP servers are launched from whatever command the user configured (the built-in presets use unpinned @latest packages), and a bundled ClawHub skill tells the model to install skills from a public registry with 'npx --yes clawhub@latest', which the model can run through the ungated shell. A malicious extension runs with the user's full authority.

API keys, chat-bot tokens and email passwords live in ~/.nanobot/config.json, either in plaintext or as ${VAR} references, and nanobot does not enforce restrictive file permissions on it. The shell tool gets a scrubbed environment so keys are not inherited by commands, and API key fields are hidden from object representations. However, in the default full-access mode the model can simply read config.json, tool-call arguments are logged at INFO level without redaction, and transcripts are stored unencrypted. Telemetry (Langfuse) is only active when its keys are set.

Every conversation is saved as a JSONL session transcript that includes tool calls, tool results and timestamps, stored outside the agent's workspace in a 0700 directory, and the runner writes a recovery checkpoint listing pending tool calls before they execute. Tool calls are also written to the human-readable log. The record is not tamper-evident, carries no actor or approver attribution, sub-agent tool calls are only summarised, and in the default full-access mode the agent's own tools could edit the files.

Each agent run is capped at 200 tool iterations, shell commands time out after 60 seconds by default (the model can ask for up to 600), and MCP calls after 30 seconds. The /stop command cancels the session's tasks, sub-agents and background shell sessions and kills shell process groups. There is no wall-clock or cost limit, each sub-agent gets its own fresh 200-iteration budget, and scheduled jobs the agent created keep running after a stop.