We can't read what you seal.And we say what we can.
End-to-end history is encrypted on your devices, and only your devices can open it. Here's exactly what the server can read, and why.
What the server can't readsealed on your devices
Turn on end-to-end history and your conversations are encrypted on your devices, with a key only your devices hold. The server stores them locked. That's all it can do with them.
History, end to end
Run 0b history mode e2e and conversations are locked before they leave your machine. Only your devices can search them.
A new machine needs your approval
You approve it from a machine you already have. The server passes the key along but can't read it, and both screens show the same code.
A recovery key you keep
If you lose every device, the recovery key you saved opens what you sealed. We can't recover it for you.
What the server can readand why it has to
Some things the server has to read to do its job. Each one is kept to what that job needs.
Your service logins
The OAuth tokens and API keys of the services you connect. To call Linear for you, the server has to use your Linear login.
They're stored encrypted and used only to make the calls your tools ask for. Disconnecting a service deletes them.
Conversation history, if you turn it on
Off until you run 0b history on. By default the text is stored readable, so your coding agents can search it through 0bridge; text shaped like keys is masked on your machine before upload.
Want it sealed instead? 0b history mode e2e encrypts it with your vault key, and search runs on your devices.
Session states, webhook events and token counts
If hooks are on, the session board gets each session's state, repo, branch and up to two short lines of text (text shaped like keys masked first, and none at all with end-to-end history). Webhooks you create store their events for 7 days by default so they can be routed.
Token counts per session, model and hour are counts only, never text, and stay readable by the server even with end-to-end history, so it can add them up. 0b usage off stops them.
The audit log
Sign-ins, changes to connections and tokens, and for each tool call: which tool, whether it worked, how long it took and when (with a short error message if it failed).
Never what was sent or what came back. Rows are deleted after 90 days; encrypted backups can hold them up to 12 weeks longer.
Signing inand every device you've signed in on
Your account is the key to your logins, so the steps that hand out access ask you to prove it's you again.
Email code, Google or GitHub
Add a passkey under Settings for the strongest sign-in. Ten recovery codes, each used once, cover a lost passkey.
Re-confirm what matters
Approving a new device, giving an app access and creating a token need a sign-in from the last 10 minutes, with your passkey if you have one.
A token per device
Each machine signs in with its own token, which the server never keeps in readable form. Signing out revokes it, and Settings → Devices revokes any of them.
Claude and ChatGPTget your tools, not your keys
Chat apps connect as custom connectors, with a consent screen you approve. Setting them up
You approve each app
The consent screen shows the app and where it sends you back to. Its access works only for your 0bridge and expires within an hour.
Can't add keys
Apps connected this way can call your tools. They can't add API keys or tokens.
History in chat apps is a switch
Claude and ChatGPT get history tools only while chat history is on. New accounts start with it on; any app can turn it off when you ask, turning it back on takes the dashboard, and it is never offered through a directory listing.
Source availableand honest about what's next
You shouldn't have to take our word for the parts that hold your key.
Read the client
The 0b CLI and the core library it shares with the dashboard, including the code that encrypts your history, are published at github.com/0bridge/cli for anyone to read (source available, under the FSL license). Each version becomes Apache 2.0 two years after its release.
What we're still working on
- A device's token can do most of what your account can, short of creating tokens. App tokens you mint on the dashboard can be narrower, and a project's token opens only that project.
- Your profile, memory and skills, and the text of agent tasks, are readable by the server: chat apps have to read them. Don't keep secrets there.
- Revoking Claude's or ChatGPT's access from the dashboard isn't there yet; remove it in the app.
- Tool descriptions from services you connect reach your agent as those services wrote them. Treat an unfamiliar MCP server like any code you'd run.
Found a problem?Tell us first.
Send it through our contact form: it goes privately to the team, and security reports get an answer first. Please don't post them publicly before we've replied.