CLI is all you need.

~/notes

1. [1] New accounts get $5 of credit for managed models through the co/ prefix, so nothing needs an OpenAI, Anthropic or Google key on day one. Those requests route through OpenOnion's proxy; put your own key in .env and change the model string whenever you like. The agent runs on your machine. co deploy hosts it on ConnectOnion Cloud, and co deploy --to puts it on a server you own. Register servers with co server. ↩
2. [2] co browser runs a daemon that owns one real browser, so a login you complete by hand, including 2FA, stays valid for every later command. Forty operations, listed by co browser help; co browser do "…" puts an agent on the same live browser. Several agents can share it: each opens its own tab with co browser tab open, and co browser tab ls shows every tab and who owns it. ↩
3. [3] The chat is a web page, so the person you send it to doesn't install anything or sign up. Their key is generated in their own browser and never sent to us. Because it lives in that browser, a different browser is a different identity unless the recovery phrase is imported. Traffic reaches people outside your network through our relay, which terminates TLS and can read it. It is not end-to-end encrypted. ↩
4. [4] The agent edits dashboard.html with ordinary file tools; the host notices the change and pushes a snapshot after that run; the pane re-renders. No polling, no fetch, no deploy. Capped at 2 MB with images inlined. The generated starter carries up to four skills as buttons, and agent-authored HTML runs under default-src 'none' in an opaque-origin frame, so it cannot call out. ↩
5. [5] .claude/skills/ and ~/.claude/skills/ are in the load path; co skills discover also scans Codex, Cursor and Kiro. One difference: we read the tools: key, not Claude Code's allowed-tools, so a skill's auto-approvals do not carry across. Its instructions run unchanged, but it asks for permission more often. ↩
6. [6] Requires the codex binary (npm install -g @openai/codex). Sandbox levels are read-only, workspace-write and danger-full-access; per-action approvals reach you through the same approval card as everything else. ↩
7. [7] co auth google and co auth microsoft run the consent through OpenOnion's OAuth app, so you don't set up a cloud project or consent screen or wait for a review. The credentials come back encrypted to a one-time key your CLI generated, and are saved only on your computer. Calendars are there too: co gcalendar and co outlook calendar. The agent's own mailbox (0xcbef…@mail.openonion.ai) is an OpenOnion-hosted service that activates after co auth. It is not a mail server on your machine, which is why you add no DNS records. ↩
8. [8] A fixed set of tool names counts as dangerous: bash, shell, file writes, background tasks, email and delete. A custom tool you add is not in that set and runs without asking, so name it in your .co/host.yaml permissions if it should be. Approvals need a frontend attached: with no chat UI connected there is nothing to ask, and tools run. co call sends bash, not a tool call, so a whitelist entry for the read tool does not permit a read command. ↩
9. [9] The 12-word recovery phrase is the only way back. If you lose it, the address is gone, and no reset link or support ticket can restore it. .co/keys/ carries a DO_NOT_SHARE warning file. The address itself is public by design: it is the same string you hand out as a chat link and an email address. ↩
10. [10] Every session on this page is simulated. The commands and the output strings are copied from the CLI's source; the data (addresses, file names, row counts, the client) is invented. The chat, Home and approval screens are drawn from the real components, with invented content. ↩

Apache-2.0. Works with OpenAI, Anthropic, Google, Groq, Grok, OpenRouter and Mistral, or managed keys through the co/ prefix.