Connect your AI agent to Gmail, a real browser and your files — one command each.

~/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 those with co server. ↩
2. [2] co browser runs a daemon that owns one real browser, so a login you complete by hand — 2FA included — 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 installs nothing and signs up for nothing — 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 — 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 — that is why there is no cloud project, consent screen or review queue on your side. 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 — not a mail server on your machine, which is what makes the zero-DNS claim true. ↩
8. [8] A fixed set of tool names counts as dangerous — bash, shell, file writes, background tasks, email, 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 — 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 — lose it and the address is gone; there is no reset link and no support ticket that restores it. .co/keys/ carries a DO_NOT_SHARE warning file for a reason. 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.