What's new,release by release.

0b update to get it.

• A folder from 0b drive clone now syncs only when 0b drive sync runs in it. Run it right before you (or an agent) read or edit the folder, and right after writing; the background job no longer syncs Drive folders every 15 minutes. The 0bridge skill tells coding agents to do exactly that. Drive folders on your computer
• 0b webhook add and set offer the two routes webhooks have now, run and listen (--notify works on either); forward, agent, notify and Routine (and 0b webhook forward-secret) are gone from the CLI too. Triggers and webhooks

0b update to get it.

• 0b webhook listen <name> waits for the webhook's next event, prints it as JSON and ends. Run it in the background from Claude Code (or any session): when it finishes, the session gets the event, handles it, and listens again. An event that arrives while the session is busy comes at once on the next listen, so nothing is missed; 0bridge pushes the event to the waiting command, nothing polls. Any webhook can be listened to, whatever it does with its events. Listen
• Webhooks now do one of two things: run a command on your machine, or a session listens (what was called Store; --route listen, and store still works). The forward, agent, notify and Routine routes were removed on the server: a command does any of that, and "also notify me" (--notify) still works on either (a webhook that notified keeps notifying). A webhook that had one of them keeps its address and events, now as listen. This version's 0b webhook add still lists them; picking one is refused, and the next CLI drops them. Triggers and webhooks

0b update to get it (on the dev machine for the delivery receipts).

• When your AI app has shown you the team's messages and questions from a machine with a work ledger (0b agent supervisor ledger), it can now say so: bridge__ledger_append with action delivered in ChatGPT and Dots (bridge__host_delivered elsewhere) records a delivery receipt for each in the ledger (host-task delivered, channel dots), naming the app, the time and the call, so the team can tell from the ledger that you saw them. Only recent team messages 0bridge has from that machine count; nothing is sent anywhere and no question is answered or closed. bridge__host_updates now gives each team message its event id for this. A machine on an older 0b is asked to update. Dots and your dev host
• 0b exec waiting for your approval of a protected environment (--env prod) no longer stops at one server error or dropped connection: it keeps asking every 2 seconds until you approve, deny, or the request expires. Secrets

0b update to get it.

• 0b context sync used to stop with an error, every time, once a profile, instructions or skill this machine knew had been removed on 0bridge (deleted in Drive, or 0b context rm on another machine). Now it finishes. Unchanged here, a skill is removed here too, and a profile or instructions stay here without being sent back until you change them; changed here, this machine's copy goes up again as new; one written on 0bridge again since comes down. Memory and context
• 0b host request, followup and answer send through bridge__execute_write, as an app's changes go in code mode. They keep working where 0bridge refuses a write called by its own name; reads go by name as before. Dots and your dev host

0b update to get it.

• 0b host receipts [--since 30m] lists what this token sent to your dev host lately and where each stands, never the words. --key <id> on 0b host request, followup and answer makes a retry safe: the same send again with the same key records nothing new. Dots and your dev host
• A session that needs you says what for: an approval, your input, or an unverified notice, and it shows as unconfirmed once its machine can no longer tell (the session board and 0b sessions). Sessions
• With CLAUDE_CONFIG_DIR set outside your home folder, a run from a temporary home no longer writes into it.
• Released without GitHub Actions: tested on Linux before release, and the npm package no longer carries a provenance statement.

The policies now say who runs 0bridge: 0bridge (support@0bridge.dev, privacy@0bridge.dev), from Korea. There's a privacy policy in Korean, the Data Processing Agreement has the annexes the EU's Standard Contractual Clauses ask for, analytics cookies wait until you accept them, and a trial or a higher price turns paid only when you say yes. The new Terms, Privacy Policy, 개인정보 처리방침, DPA and sub-processor list apply from today, October 13, 2026.

Analytics cookies#

• The first time you open 0bridge.dev or the dashboard, you're asked about analytics cookies. Accept and Reject are the same size, and nothing is chosen for you. Until you choose, and if you reject, PostHog only counts page views, with nothing stored on your device and nothing linked to you.
• Change your mind any time with the Cookie settings button in the privacy policy, or in the dashboard's account menu. Do Not Track and Global Privacy Control count as Reject.

Nothing turns paid without a yes#

• A Team trial asks before it ends. From 7 days before, the workspace's owners get an email and the dashboard asks: "Your Team trial ends on Oct 12. Continue at $15 per seat (3 seats ≈ $45/month)?" Answer any time during the trial, in Settings › Billing or on the Team page. With no answer 3 days before the end, it's set to end with the trial and the card isn't charged; Continue still works until then.
• A higher price is announced at least 30 days ahead, and asked about from 30 days before the renewal it would first apply at. Accept, and it applies from that renewal; don't, and the subscription ends at the end of the period you paid for.

Policies#

• Privacy Policy: who we are, the legal basis for each use, your rights and where to complain, how data leaves Korea and the EU, a cookies section, and everything the server can read (session board lines, token counts, webhook events, the clipboard) listed.
• 개인정보 처리방침: the Korean policy, with the items Korean law asks for, from the transfer table to the privacy officer and where to seek redress.
• DPA: what is encrypted on your members' devices and what the server reads, said plainly; transfers from Korea; Annexes I to III for the Standard Contractual Clauses.
• Terms: Korean law, with consumers keeping the protection of their own; consumers can withdraw within 14 days of their first payment for a full refund; a trial turns paid, and a price goes up, only with your consent.

A session that needs you now says whether it's a pending approval, waiting for input, or an unverified permission notice, when its hook saw it, and when its machine can no longer confirm it. bridge__agent_sessions counts the sessions it hides, and bridge__agent_send has a dry run. What a session that needs you waits on

• Three kinds. A pending approval is a typed permission notice or a permission request that names its tool. Waiting for input is a question, an MCP server's request, or a worker that needs input. Unverified is a permission notice 0bridge can't vouch for: no type, only the word "permission", or a request naming no tool (and it says when the session runs with permissions skipped). A typed notice or a request naming its tool is a pending approval in every mode.
• No wait left standing. A waiting session's machine watches its transcript for 10 minutes. When that runs out, or the transcript can't be read, the board shows it as unconfirmed since then, with the time it was seen, instead of needs you forever. If the machine itself goes quiet (0b stopped, machine off, updates failing), the board marks the wait unconfirmed after 12 minutes on its own. A task started from 0bridge whose prompt 0bridge holds always shows as a pending approval, even when its session's hooks say it's working.
• Shown everywhere: the Now page, 0b sessions and bridge__sessions_status, whose header counts them apart (2 need you (1 unverified or unconfirmed)). A notification for an unverified one says "may need you".
• Nothing approves from the board. The board's lines are what a hook reported, not the screen now. The Now page's button is "How to answer" and says to answer on the machine.
• An empty session list says why. bridge__agent_sessions reports how many sessions it found outside the repos you allowed, and why (for example "no repo is allowed on this machine"), without naming them, and where it looked.
• bridge__agent_send with dryRun: true sends nothing. The machine says whether it would take the follow-up now, why not, and the route: herdr, tmux, codex queue or a headless resume. It also warns that herdr and tmux type the text and press Enter, which answers whatever prompt is showing. A refused send now lists the repos that machine allows. No permission changed: 0bridge doesn't widen repos or typing, and adds no way to send.
• Machines report the kinds, the hidden count and the dry run with the next CLI release. Until then, older machines show their waits without a kind. Tested with fixtures for each cause, not yet on a live session.

When your dev machine keeps a work ledger, apps now get a fifth tool next to the four: bridge__ledger_append, which only adds your request, follow-up or answer to that ledger. Sends can carry a key so a retry is recorded once, and bridge__host_receipts shows what reached the host. Check that a send arrived

• bridge__ledger_append (action request, followup or answer) runs the same host tools as before, with the same checks, and reaches only a machine whose supervisor is the work ledger. It's marked as adding without deleting and without reaching outside, so ChatGPT weighs it as what it is. bridge__execute_write still runs the host tools too.
• It appears only for an account with agent control on and a machine set up with 0b agent supervisor ledger; nobody else's list changes. Refresh 0bridge in the app once to see it.
• bridge__host_request, host_followup and host_answer take an optional key, such as the chat message's id: the same send again with the same key from the same app returns the first result and records nothing new, also after a reply that never came back. A key reused for a different send is refused, never mistaken for the old one; keys hold for a day.
• bridge__host_receipts lists what this app sent lately (requests, follow-ups, answers), with its key and where each stands, never the words. In a terminal: 0b host receipts --since 30m, and --key on 0b host request, followup and answer (with the next CLI release).
• Tested with the machine hub's tests and a stand-in ChatGPT list, not yet in ChatGPT or a real dot.

0b update to get it.

• 0b host answer <question> --task T-012 "…" names the task the question is on, and the answer is refused if that question is on another task, so a short "A" can't land on a different open question. AI apps answering through 0bridge (bridge__host_answer) pass the task the same way. Dots and your dev host

0b update to get it.

• On a machine with a work ledger, every message the team sends you now reaches your app, not only those about work you asked for there: results and follow-ups come as progress on any task, and the host's own notices (server alerts, usage summaries, schedule briefings and reminders) as notice, with their kind. 0b host updates --kinds …,notice reads them from a terminal. Dots and your dev host

0b update to get it.

• On a machine with a work ledger, when you answer one of the team's questions after they had already moved on (a newer message on the task closed it), your answer is no longer refused: it's recorded as your decision on that question, with its option and a note that the question had closed, so the team sees it and decides. Dots and your dev host

0b update to get it.

• 0b host request "…", 0b host followup, 0b host answer <question> "…" --choice A, 0b host status, 0b host questions and 0b host updates --cursor … hand work to your dev host's work ledger and read its questions and results back, from any terminal: an AI agent's computer such as a dot's, or your own. Dots and your dev host
• On an agent computer (0b setup --agent-vm) these work only with a machine whose supervisor is the work ledger; that computer still can't see or steer your machines.
• 0b agent supervisor ledger|openclaw|off tells the running agent at once, so the change takes effect without waiting.

A dot's computer, or any machine you're signed in on, can now hand work to your dev machine's work ledger from its terminal, without the chat app's tool list: 0b host request "…" calls the same host tool Dots and ChatGPT do, by its name. From a terminal

• 0b host request, status, followup, answer, questions and updates. request prints the request's id (hr_…); updates ends with the next cursor, so a scheduled job can keep it. - reads the text from stdin, --json is for scripts, and a refusal exits non-zero.
• An agent computer (0b setup --agent-vm, a 7-day token you can revoke on the dashboard) may now use these six host commands, and only for a machine in ledger mode (0b agent supervisor ledger), where every one is an entry in the ledger. A machine on the OpenClaw supervisor refuses it and says why. It still can't list your machines or start coding agents.
• Comes with the next CLI release (0b update).
• Tested against a stand-in gateway and the machine hub's tests, not yet from a real dot.

0b update to get it.

• 0b apply --only cursor --tool-search all now gives that tool's 0bridge entry the address ending in ?tools=all, which lists every tool one by one. --tool-search code goes back to the plain address: the four tools that find and run the rest and never need a refresh. Never refresh again
• 0b settings says that chat-tool-search only matters on a ?tools=all address.

0bridge no longer lists every connected service's tools one by one. Every app gets the same four, whatever you connect or switch on, so ChatGPT, Dots, Claude and the rest never need a refresh again. How it works

• bridge__search finds a tool by a few words, among your services' and 0bridge's own; bridge__describe shows its parameters.
• bridge__execute runs tools that only read: one by name, or several in a short script, so a task that reads five things comes back in one answer. Scripts run on 0bridge in a sandbox with no network; all they can reach is your tools.
• bridge__execute_write runs tools that change something, and your app asks you first.
• Every tool run this way gets the same checks as before: tools you turned off, read-only connections, token scopes, your plan's calls (each tool a script runs counts).
• Apps that still have the older list keep working: tools by service name still run. Refresh 0bridge in the app once to get the four tools.
• Want every tool listed? Use the address ending in /mcp?tools=all.

ChatGPT, and the Dots that use your ChatGPT app, keep a copy of 0bridge's tools and read it again only when you click Refresh, so a new connection or a changed setting didn't reach them until you did. A new switch gives them a tool list that never changes: they find your services' tools and the rest by searching. ChatGPT

• Turn on Never refresh 0bridge in ChatGPT under Settings → AI apps, or run 0b settings on chat-tool-search (in the next 0b release), then refresh 0bridge in ChatGPT once.
• From then on the app finds tools with bridge__tool_search and runs them with bridge__tool_call (reading) or bridge__tool_call_write (changing something). A search follows your connections and settings as they are now, and every call gets the same checks as before.
• The trade-offs: each call takes two steps, and ChatGPT asks you to confirm every change.
• Off by default, so nothing changes until you turn it on. It needs no passkey: it gives apps nothing they couldn't already use.

0b update to get it.

• 0b agent supervisor ledger puts what you tell Dots, ChatGPT or Claude for this machine into its work ledger (host-task): a request as a dev_request, a follow-up as user_followup, an answer as user_decision, each with your words and where they came from, and reads the team's questions, progress and results back. Ledger mode
• 0b agent supervisor saves the full path of host-task, openclaw and herdr, so the background service finds them without your shell's PATH.

What you tell Dots, ChatGPT or Claude for your dev machine can now go into the work ledger there (host-task) the same way your desk and Telegram already put it: a request as a dev_request for the team to take up, a follow-up as user_followup, an answer as user_decision, each with your words exactly and where they came from. Dots then reads the team's questions, progress and results back to you. Dots and your dev host

• On the machine, after 0b update: 0b agent supervisor ledger. 0bridge makes no task, runs no agent and types into no pane there; the team gives your request its task id.
• A request comes back with its request id (hr_…) and its place in the ledger, not a task id: bridge__host_status request=hr_… says it's waiting, then shows the task once the team has made it.
• The team's questions with options ([선택지]) arrive as host.task.question with those options; answer with bridge__host_answer, picking an option with choice.
• 0b agent supervisor now saves the full path of host-task, openclaw and herdr, so the background service finds them without your shell's PATH.
• Tested on a local copy with stand-ins for the host's tools; not yet on the real machine or with a real ChatGPT account.

0b update to get it.

• 0b login asks for your vault in the same sign-in: the one passkey prompt on the approval page also gives this machine your vault, so a new machine no longer needs a separate 0b vault unlock. The code on the page is made from the machine's key, so a swapped key would show a different code than your terminal. Signing in by email number or on an agent VM still keeps the vault as its own step. Secrets
• 0b settings shows your account's switches, and 0b settings off agent-control|chat-events|chat-history turns one off from the terminal or from any agent. Turning one back on is in Settings → AI apps, with your passkey.

New accounts start with Agent control, Webhook events in chat apps and History in chat apps on, so a chat app can reach your agents, your webhooks' events and your past conversations without a trip to Settings first. Any AI you use can turn them off again. Claude and ChatGPT

• Accounts that already existed keep their settings. To turn these on, open Settings → AI apps on the dashboard; it asks for your passkey, as before.
• Any agent or chat app can turn one off when you ask it to: bridge__settings_off over MCP, or 0b settings off agent-control|chat-events|chat-history in a terminal (in the next 0b release; 0b settings shows where each stands).
• Turning one back on is still only on the dashboard, with your passkey.
• Each machine still opts in to agent control with 0b agent on, per repo, and the directory listings' review account never gets history.

0b update to get it. It brings the machine's side of your dev host from Dots, ChatGPT and Claude, Trello comments for the tasks on that host, and connection lists that say whether agents can use a connection, not only whether it's signed in.

• 0b agent supervisor openclaw --agent lead sets the host's supervisor: requests and follow-ups from your AI apps reach it, and a worker's question, result or failure comes back to you. An answer is typed into the worker that asked.
• 0b webhook create --preset trello --board <id> makes a Trello board's endpoint, and 0b webhook trello-relay turns on, on that host, passing a card's comments to the worker of the task it's linked to. A comment is never folded together with another.
• 0b tree and 0b connection say ready only when agents get a tool. Signed in with every tool off is tools off (still signed in; turning tools off isn't disconnecting), some on is in use with how many, and a sign-in problem shows as one whatever its tools are set to. 0b connection <service> says how to get the tools back.

Hand work to the OpenClaw supervisor on your own development machine from any AI app, get a task id at once, and hear back when a worker asks a question, finishes or fails. Your answer is typed into the worker that asked, and 0bridge tells you it took it. Nothing goes through Slack. Dots and your dev host

• On the machine, after 0b update: 0b agent supervisor openclaw --agent lead. The supervisor is set up there, never from 0bridge's side.
• Six tools, with agent control on: bridge__host_request, bridge__host_status, bridge__host_followup, bridge__host_questions, bridge__host_answer and bridge__host_updates.
• MCP events the way ChatGPT supports them (Work chats and dots): host.task.question, host.task.completed and host.task.failed, signed per Standard Webhooks; your webhooks' events as webhook.received.
• Claude, which has no MCP events, asks with bridge__host_updates, and an ntfy topic or email tells you a worker is waiting, without the question's text.
• Tested on a local copy with stand-ins for ChatGPT and the host's tools; not yet with a real ChatGPT account or dot.

A skill that was never on 0bridge, like one a tool installed for itself, now stays on your machine until you choose. Before, 0b import and the background sync uploaded every skill they found, so it reached your other machines and your chat apps. Profile, memory and skills

• 0b skill share <name> uploads one. 0b skill local <name> keeps it on this machine and stops asking.
• 0b status lists the skills waiting for your call, and an interactive 0b context push asks once.
• Skills you add with 0b skill add, and skills already on 0bridge, sync as before.

0b context push stopped at the first skill 0bridge refused (more than 100 files, or over 256 KB with its files), and none of the skills after it went up. Now that skill stays on this machine with a note saying why, and the others are uploaded.

• BROWSER=none opens no browser on any OS; sign-in prints the link instead.

A Drive folder with a README.md is a piece of work, and now its conversations are filed with it. Start a quote in Claude Code, say "continue that quote" in ChatGPT, and it finds the folder, reads where the work stands, and picks up the conversation. Drive

• The folder's README.md is the current state every app reads first. Changing one that exists needs the version the app read, so a newer state is never quietly overwritten.
• bridge__session_save takes folder to file a conversation under a work folder, and saves nothing when the name doesn't match one. Coding sessions run inside a 0b drive clone folder are filed on their own (CLI 0.2.26).
• Listing a work folder shows your conversations filed there; bridge__resume brings the README as it is now and says whether it changed since; bridge__drive_search lists matching work folders first.

Channel Talk calls a webhook with a token it makes itself (?token=…), not the one in the address you paste. 0b webhook token <name> gives 0bridge that token, typed hidden, so its deliveries are accepted. Webhooks

• A refused delivery (wrong token or signature) now shows on the webhook in 0b webhook list and the dashboard, with its time, instead of failing silently.
• 0b webhook add --preset channeltalk prints the address without a token and the step to copy Channel Talk's.

Drive now reads PDFs, Word and Excel files and photos, takes mail, keeps versions, and treats a folder with a README or AGENTS.md as a piece of work any AI app can pick up, from Claude to Claude Code, with the same instructions and skills. Webhooks can run a command on your machine or forward an event, signed. A line marked not verified hasn't been checked on the real product yet.

Folders as pieces of work#

• A Drive folder with README.md or AGENTS.md is a piece of work. When an AI app lists it, it sees the folder's instructions, the README and the skills under .agents/skills/ first, and the skills are offered in bridge__skills and as prompts. Drive
• Apps can't rewrite a folder's instructions through Drive. When one changes AGENTS.md, a skill or .mcp.json, the change waits under Drive → Proposals with a diff, for you (or a team's owners and admins) to apply or reject.
• Every save is a version. Restore one from the file's panel, or ask an app to with bridge__drive_restore; deleted files come back the same way.

PDFs, Word and Excel files, and photos#

• Text in PDFs, Word and Excel files (and OpenDocument and Numbers) and photos is extracted, so search finds it, Korean included, and apps read it with page numbers. Page markers on real PDFs and text from Korean photos are not verified.
• A scan warns when a file looks like it holds a resident registration, card or account number. It never blocks the file.

Mail into a folder#

• Give a folder an address under Drive → Email. Mail from a member's address that passes our own DKIM check is filed into the folder, attachments and all, and the sender gets a receipt. Anything else waits in Drive → Inbox for you to accept or reject. Mail on the real 0bridge.dev domain is not verified.

Drive folders on your computer#

• 0b drive clone <folder> ~/projects/<name> keeps a Drive folder, your own or a team's, in sync with a folder on your computer, both ways, in the background. When both sides change a file you keep yours and get theirs next to it. Skills and CLAUDE.md are linked for your coding agents. Sync on Windows and macOS is not verified. CLI
• 0b drive ls, status, sync, unlink and email.

Webhooks that run or forward#

• Run: 0b webhook run <name> -- python3 sync.py runs your command on this machine whenever the webhook gets an event, with the event on its standard input. The command stays on your machine. If the machine is off, the event waits and runs once when it's back. Running it on Windows and macOS, as a background service, and against the live service is not verified. Triggers and webhooks
• Forward: send events on to your own server, signed (Standard Webhooks) with a secret shown once. Forwarding to a real public https receiver is not verified.
• Events that are only kept are now called Store: stored for agents to read. 0b webhook add asks what to do with events.
• A recipe for Channel Talk replaces a polling timer with a webhook that runs your sync script.

Three things the local sync couldn't do yet.

• 0b skill add <folder> adds a skill you wrote or downloaded to the ones every tool gets. It checks the folder first: SKILL.md with a name and a description, not a whole repo. Command reference
• A repo's own MCP servers and skills: 0b mcp add --project and 0b skill add --project in a clone, then 0b apply writes them into Claude Code, Codex and Cursor there, kept out of git, never over a file you committed. 0b project import takes in what a clone already has. Claude Code also reads the repo's AGENTS.md when there's a CLAUDE.md next to it. Projects
• 0b use picks which Claude Code or Codex account a repo, a shell or the whole machine starts with: 0b use add work, then 0b use work in a repo. Every account gets the same servers, skills and instructions, and history reads each one. Command reference
• Cursor gets your skills in ~/.cursor/skills when Claude Code and Codex don't already have them. Cursor reads their folders too, and a second copy would show up twice.
• Strict projects in Cursor: 0b project link says that Cursor keeps the global 0bridge next to the project's, and how to turn the global one off there.

Your history, instructions and coding agents now go with you from one AI tool to the next. The command-line side comes with 0b 0.2.19: run 0b update. A line marked untested or not verified hasn't been checked on the real product yet; the linked doc says what has.

Resume anywhere#

• Every session gets a short reference like 0b:k3f9x2. Copy it from the dashboard's History page, say continue 0b:k3f9x2 in another tool, and it picks up the goal, the open items and the last turns. Resume anywhere
• 0b resume continues a session from the terminal: the tool's own resume on the machine where it ran, anywhere else the tool you pick, started with the handoff.
• A chat app or a coding agent can save where a conversation got to with bridge__session_save, so another tool can pick it up.
• Claude and ChatGPT search and resume your history only if you turn on chat history in Settings. It's off by default, and turning it on asks for your passkey.

Sync as each turn ends#

• With 0b history hooks on, a conversation uploads a few seconds after each turn ends instead of waiting for the 15-minute background job. Claude Code, Codex and Cursor are covered. Cursor running the hook on every turn is not verified.
• The background job runs on macOS, Linux and Windows.

Your context in every tool#

• One profile, global instructions, skills and searchable memory that every AI tool you connect can read. 0b context keeps them as files on your machines; chat apps read them through 0bridge. Profile, memory and skills
• The server can read them, because chat apps have to. Text shaped like keys is masked; keep secrets in the vault.

More tools, one session format#

• History from Gemini CLI (every 15 minutes, since it has no turn-end hook), Cursor's command-line agent, OpenClaw, a second Claude Code folder and CODEX_HOME.
• Hermes Agent sessions are read too untested: no Hermes install was available to check against.
• @0bridge/session, the 0b.session/1 schema and the converters that read each tool's logs, is a package under the Apache 2.0 license. It isn't a standard.

Your coding agents from your phone#

• Start and steer Claude Code and Codex on your own machine from Claude, ChatGPT or the dashboard. Off by default for the account and for each machine (0b agent on), and only in repos you allow. Your agents from your phone
• Each task runs in its own git worktree and branch. Permission prompts come to you; pushing to main, merging and deploys are denied by default.
• A finished task with a signed-in Claude Code and Codex is not verified: the real agents started and answered, but not yet signed in. Gemini is best effort.

Every session on one board#

• One list of what your Claude Code, Codex and Cursor sessions are doing on every machine and in the cloud (working, needs you, idle, ended, error), the ones waiting for you first, with an optional notification. Session board
• It's a few seconds behind, not streamed. Claude Code reporting "needs you" is not verified on a real session, Codex can't report questions, and Cursor has no permission hook.

Webhooks that wake an agent#

• Give a service like Channel Talk or GitHub a webhook address: 0bridge checks the signature, keeps the events for 7 days, and can wake an agent in plan mode, call a Claude Code Routine or notify you. Triggers and webhooks
• events/list and events/poll follow the MCP Triggers and Events working group's draft. They're experimental and the draft may change.
• The Channel Talk recipe and the Routine route are untested against the live services.

Agent computers#

• 0b setup --agent-vm sets up your dev environment on an AI agent's own computer with one command: no prompts, an approval link, and a token that expires in 7 days. Agent computers
• Meta Muse, Manus, OpenAI Dots and Grok Bot are untested. Instinct isn't supported: it has no terminal and no MCP.

Approvals#

• A machine without a browser prints the sign-in link first, shows a QR code on a wide terminal, and you approve it on the dashboard by matching a 2-digit number, with your passkey. Approvals and sign-in
• 0b login --email you@example.com puts the request on that account's dashboard, and a notification can tell you about it.

Usage#

• Tokens per tool, model, repo and day, with an estimated cost at API list prices. Counts only, never text; the server can read them even with end-to-end history, and 0b usage off stops them. Usage
• The log fields for Claude Code, Codex and Gemini CLI come from samples; checking them against real logs is not verified.

Tokens for apps and cloud agents#

• App tokens from the dashboard pick which tools, history and agent access an app gets, and when the token expires (90 days by default), for any MCP client that takes a URL and a token.
• 0b project cloud sets a repo up for Claude Code on the web: the MCP config, a project token read from ZEROB_TOKEN, and hooks that upload the session. Every cloud session running the hook is not verified. Cloud agents

Windows and Linux#

• The CLI runs on Windows, with secrets under Windows' own protection and jobs in Task Scheduler, and on Linux with secret-tool when it's there and systemd user timers. Windows is new: tested in CI, and on a real Windows machine not verified.

A new site#

• New docs for supported clients (each dated), resuming, remote control, the session board, agent computers, approvals, webhooks, usage, memory and switching tools, plus comparisons, Why no lock-in, a changelog and its Atom feed.
• Product updates by email, about once a month, if you turn them on in Settings. Every one has a one-click unsubscribe.

Tell us what's wrong from the dashboard, the terminal or your AI tools, and join team early access with a short form instead of an email.

• Feedback at the top right of the dashboard (in the account menu on a phone): a problem, an idea or something else, with the page and browser if you leave that on. Send feedback
• 0b feedback [message] sends one from the terminal. --include-logs adds the last lines of 0b's own logs, masked, and shows them to you first; it always asks before sending.
• Agents and chat apps have bridge__feedback. When 0bridge itself fails, they can offer to send a detailed report, and they're told to show it to you before sending. Any app or token can use it, 10 reports an hour per account.
• Key-shaped text in a report is masked on the server before it's stored, and 0bridge device tokens are now masked like other keys everywhere text is masked. Security
• Join early access on the site now opens a short form after you sign in: your team's name and size, the AI tools it uses and what you want to do. You can change or withdraw it there. Pricing and teams

Smaller releases from the last few days, newest last.

• 0b secret import --dry-run lists the names first and --only moves just the ones you pick; 0b exec sets ZEROBRIDGE_ENV (0.2.9).
• 0b connect asks how to connect: an MCP server, an API or a CLI, with Slack through 0bridge's app by default. 0b project hide keeps a connection out of one project (0.2.10).
• A second Claude Code folder (~/.claude-*) gets the same setup as ~/.claude (0.2.11).
• Several 0bridge accounts at once: 0b login adds one, 0b account lists them, and a linked repo can use its own (0.2.12).
• 0b profile add finds a repo's own wrangler, and its sign-in works over SSH (0.2.13).
• An image copied as TIFF reaches your agents as a PNG they can see (0.2.14).
• 0b update installs the newest 0b with the package manager that installed it.
• ⌃V in Claude Code on a server pastes the image you last copied on your Mac: 0b clip shims and 0b clip sync on (0.2.15 to 0.2.18).
• On the site and dashboard: Pricing and Security pages, deleting your account from Settings, and the client's source at github.com/0bridge/cli (source available).

The first week after launch.

• 0b clip and the dashboard's Clipboard page send a screenshot, a file or text to your agents anywhere. Each item is read once and gone after 10 minutes. Clipboard
• On a Mac, 0b clip listen on lets an agent ask for what you've copied; a dialog asks you first.
• Connect any service: 0bridge's list, the official MCP registry, or an API from its OpenAPI document. Connections and APIs
• A Channel Talk connector (0.2.6).
• 0b project link and 0b project status show agents and connections as trees (0.2.5).
• 0b connect slack --app own|0bridge picks which Slack app signs in (0.2.7).
• 0b status: a setup checklist for this machine and this repo.

The first release, on npm as 0bridge.

• One MCP endpoint at 0bridge.dev holds the services you connect, and Claude Code, Codex, Cursor, Claude and ChatGPT all use it.
• Several accounts of one service, each with its own label, so tools are named like linear__work__create_issue.
• The 0b command: sign in with a code from your browser, then sync your MCP servers and skills across the AI tools on your machine.
• Sign in to the dashboard with an email code, Google or GitHub.