nanobot

Not restorable in one action: the ~/.nanobot directory is complete and immediately available, but there is no export or import command, so it (plus any custom workspace with its .nanobot/workspace-id marker) must be copied by hand to the same path on the new machine.

• Deployment guide
• Troubleshooting: session storage and workspace moves
• Runtime path helpers

The instance directory holds everything that defines the agent: configuration, instructions (AGENTS.md, SOUL.md, USER.md), memory and its Git history, session history, cron jobs, skills and credentials. The runtime itself is a separately installed open-source package.

• Concepts: memory and sessions
• Memory design

The runtime is an MIT-licensed Python package that runs locally and can use local OpenAI-compatible servers such as Ollama or vLLM, so it operates without contacting any HKUDS server.

• Provider registry (vLLM, Ollama)
• LICENSE

The agent has no identity of its own that contacts can verify: after migration they recognize it only through the chat-channel accounts whose tokens travel in config.json, relying on each platform. The workspace-id marker is an internal random identifier used for session lookup.

• Concepts: workspace-id
• Configuration reference

No license checks or remote flags were found; the only vendor-adjacent call is an on-demand PyPI version check with no background polling.

• On-demand version check

Tools, cron triggers, chat channels, MCP, skills and memory are executed by the runtime and offered to any provider through ordinary tool calling. Swapping to another provider, including local Ollama or vLLM models, keeps the capability set.

• Architecture
• Provider registry

Sessions are stored as JSONL, memory as Markdown plus an append-only history.jsonl, and config as JSON, all readable with standard tools such as grep and jq.

• Memory design
• Session manager (JSONL store)

System prompt templates (identity, tool contract, platform policy) ship as plain Markdown in the open-source package and workspace instruction files are owner-visible; no server-side prompt injection exists.

• Identity prompt template
• Tool contract template

HKUDS operates no hosted service for nanobot, and all derived memory (USER.md, MEMORY.md, history.jsonl) is kept in the owner's workspace. Retention by the owner-chosen LLM provider is outside the runtime's scope.

• Memory design

Session JSONL files keep assistant tool calls and tool results alongside messages, compaction preserves the originals in saved history, and automation runs write JSON run records. All of it sits in the instance directory that moves with the agent.

• Session manager
• Automation run records

Skills are SKILL.md files with optional scripts in the workspace or package, and the runtime itself is readable Python source.

• Skills loader
• Bundled skills

No advertising or sponsor channel was found; third-party content enters context only through owner-enabled tools, channels, MCP servers or skills the owner installs.

• Configuration: tools and MCP

In main sessions, pending tool calls are written to an on-disk session checkpoint before execution, so a failed write stops the turn before tools run. This is a recovery mechanism rather than a guarantee: subagent runs keep checkpoints only in memory and ephemeral sessions are not persisted.

• Agent runner (checkpoints)
• Session manager
• Subagent manager

Edits to or deletions from session JSONL files are not detectable, because entries carry no hashes or signatures. Git versioning covers memory files, not the action history, and its history can be rewritten.

• Session manager
• Git-backed memory store

By default (restrictToWorkspace false, no sandbox) the agent's shell and file tools can modify session files in the instance directory. With bwrap or seatbelt sandboxing, writes are confined to the workspace, which excludes the session store.

• Configuration: Security
• Shell tool

Session history and run records are plain JSONL/JSON and memory history is documented as searchable with grep and jq.

• Memory design
• Automation run records

nanobot has no agent-to-agent protocol and reaches other agents through ordinary chat channels. No shared identifier or receipt is kept that would let each side's record of an exchange be matched.

• Agent social network

The runtime is MIT-licensed (OSI-approved) and the release process records a provenance manifest and checksums, but no evidence of reproducible builds was found.

• LICENSE
• Release process

The runtime loads config.json from the owner's disk and WebUI settings are written back to the same file. NANOBOT_ environment variables can override file values and edits only take effect after restart, so the running configuration can differ from the file the owner inspects.

• Configuration reference
• Deployment guide

Messages can be attributed only through the chat-channel accounts the agent sends from, whose tokens travel in config.json, so recipients rely on each platform's authentication. Nothing the agent holds lets a recipient verify a message independently of those platforms.

• Message tool
• Configuration reference

The action record carries no integrity data, so no tool can check that it is unaltered.

• Session manager

All state is plain JSON, JSONL and Markdown files in the instance directory, so the owner can copy it at two points and compare the copies with standard tools. Changes to long-term memory are also committed to a local Git repository that lists and diffs versions.

• Git-backed memory store
• Memory design

Workspace instruction files (AGENTS.md, SOUL.md, USER.md) and prompts/ overrides are owner-editable, and the core prompt templates are editable Markdown in the self-hosted MIT source.

• Workspace prompt overrides
• Workspace templates

Memory is stored in editable Markdown files and history.jsonl, with Git versioning and restore; sessions can be deleted individually.

• Memory design
• Session manager

The owner can add or edit skills in the workspace and modify the MIT-licensed runtime code directly.

• Skills loader
• Skill creator

Owners can add arbitrary MCP servers, filter them with enabledTools, disable exec, add deny/allow patterns and restrict tools to the workspace.

• Configuration: MCP and Security
• Shell tool deny/allow patterns

Many hosted providers plus local Ollama, vLLM and any OpenAI-compatible endpoint are supported, with skills and tools held by the runtime.

• Provider registry
• Providers

No license checks, paid tiers or approval gates were found for any modification.

• LICENSE

`allowFrom` lists and pairing enforce, per channel, who may message the agent. Outbound, the message tool can send to any chat on enabled channels with no runtime recipient allowlist.

• Configuration: Pairing
• Pairing store
• Message tool

No per-action human approval gate was found; tools can be disabled or restricted, but selected actions cannot be made to require owner confirmation.

• Configuration: Security

/stop cancels the current task immediately and the owner can terminate the local process at any time.

• Chat commands

No telemetry or analytics code was found; outbound traffic goes only to owner-configured providers, channels and tools, plus an on-demand PyPI version check.

• On-demand version check
• Configuration reference

API keys are held in the owner's config.json and OAuth tokens (xAI, MCP) in JSON files under the instance auth directory, with logout commands that remove them.

• MCP OAuth store
• xAI OAuth store

All state is local; deleting the instance directory and workspace removes the agent entirely, and HKUDS keeps no server-side copy. Data sent to third-party LLM providers is subject to their retention.

• Runtime path helpers
• Deployment guide