Your agent gets the result.
Never the key.

Forkbench is a Mac app for running your coding agents. It keeps each piece of work in its own Thread, with its own plan, its own notes and its own keys. An agent works inside one Thread: it picks up where the last one left off, and it uses that Thread's keys by running the commands that need them, without ever seeing the values. Every pane is a real login shell, so whichever vendor's agent you put in it launches exactly as it does now. What makes people move is credentials. A capable agent you trust completely still commits a .env, echoes a key into a log, or carries an environment into a prompt, and the copy that reaches a git history is the one you cannot take back. Nothing an agent reports finished counts as done until you accept it, and closing a pane, quitting the app or rebooting leaves the tasks, the progress notes and the blockers where they were.

Yes. An agent running in your terminal has the same filesystem access you do, so a .env sitting in the project is readable, and some agents load files like that without being asked first. Whatever gets read that way becomes part of the context sent to the model provider, so a key meant only for your machine ends up on someone else's. GitGuardian's 2026 report found that code written with an agent leaks credentials at roughly twice the rate of code written without one. Forkbench does not change that, because it runs the same agent binary you run today. What it changes is where the value can live instead: put the key in Vault and the agent runs the command that needs it without the value ever entering its context.

Yes, using the macOS kernel sandbox rather than a container or a VM. A Thread can be locked to a set of folders, and every shell in it starts under a profile that denies reads and writes elsewhere under your home, external volumes and network shares. Every process the shell spawns inherits it, including build scripts and an agent's own tool calls, and it cannot be widened from inside. Builds still run, paths still resolve, and the network is untouched by that lock. Separately, a command using a key from Vault runs in a child that is denied every outbound connection except the local proxy, so the key reaches the one destination it was bound to or none. That second one is containment and evidence rather than isolation: one allowed destination is still a destination, and nothing here reads what is inside a request.

Yes, and Forkbench runs the same binary with your own flags, so nothing here adds a second approval prompt. It changes what skipping them can cost. The flag turns off the review step, not a boundary: the agent already had your files, your environment and your network, because it runs in your shell as you. Keep the credentials in Vault, where a command can use one without the agent ever holding the value, because that is the consequence you cannot undo by noticing it. Then lock the Thread to the folders the job is about, and put the session on its own worktree in a click. The human decision then moves to the end, where a finished task is accepted or not, instead of fourteen times in the middle where it stopped being read.

Yes, and if the agent is Claude Code, start with Anthropic's own Remote Control, which connects claude.ai and the Claude mobile app to a session running on your machine and is included on paid plans. Forkbench's Talk does the same attaching for whatever is in the pane, which is what you need when the one that stopped to ask you something is Codex, Gemini CLI or Aider, and a Thread shows you which of its panes is blocked instead of leaving you to check each one. It attaches to a conversation already open on your Mac and cannot start one, deliberately.

The readable text of that live conversation and its title, because rendering it in a browser and routing your reply to the right terminal is what the feature does. Raw tool output and terminal scrollback are never sent at all, and a conversation that is not on a shared board is deleted a few minutes after it stops being live. It is not end-to-end encrypted and we will not claim it is. For comparison, Anthropic documents that while Remote Control is connected the session transcript including tool activity is stored on their servers. Your notes and your Vault secrets are sealed under keys we do not hold and never work this way.

Less than you do today, and it is worth being exact about where the line falls. Three things become yours to grant rather than the agent's to take: a key you put in Vault is used without the agent ever reading the value, the notes and secrets it sees are the ones you granted that Thread, and it cannot verify or close its own work, so nothing counts as done until you accept it. What Forkbench does not do is police your machine. An agent in a terminal has the filesystem access you have, so it can still read a file you left in the project, and it only stays off your working branch if you put it on a worktree. Forkbench governs what it holds, not what your shell can reach.

Yes. Every tab is a generic PTY running a genuine login shell, not an emulation of one, so tmux, vim, htop, fzf, lazygit, your shell and your aliases all behave exactly as they do in any other terminal. Forkbench sits underneath as the terminal itself, so there is nothing to configure differently and nothing is proxied through us.

Yes, and it is built to be usable that way. Every pane is a real login shell, so your existing shell setup carries over unchanged. Be clear about the trade: Ghostty renders faster and iTerm2 is far more configurable, and neither of those gaps is closing. What you get instead is an app that knows what each pane is working on, keeps the plan when the pane closes, and hands your agents keys they can use but never read.

It depends on two things, and most answers only cover the first. How many you run: for one agent in one tab any terminal with a real login shell is fine, and Ghostty is the best free choice on macOS, while several agents from different vendors turn the limit into coordination, which is telling the sessions apart, keeping them off each other's files and keeping a plan alive past a context compaction. How far you trust the one you run: any terminal hands an agent the same environment it hands you, so a single agent reads your keys as easily as five do. Forkbench is built for both, and the second one applies whether you run one agent or ten.

It is built for it. Claude Code launches with the command you already use, in a real login shell with your hooks and MCP servers untouched. Each session can take its own git worktree in one click so two never edit the same files, Claude writes its plan and blockers to a durable board rather than into scrollback that a context compaction can take, and Vault lets it push or call a paid API without the token entering its context. It does not make Claude Code better at coding, because it runs the same binary you run today.

They stop being a flat row of twenty tabs you have to remember. Related tabs live in one Thread with its own folder, its own notes and secrets, and its own board, so switching context is switching Thread rather than hunting for the right window. Nothing in one Thread reaches into another unless you grant it.

Yes, that's the whole idea. Give a Thread one objective and it becomes a backlog they pull from: they claim tasks, work in parallel, and hand off, with no two on the same thing. You stay the lead: an agent can add and start a task on its own, but it can never verify its own work, and an agent reporting a task finished does not make it done until you accept it.

Through the Thread's board. Every Thread has one from the moment you make it: an objective, a backlog, and a lease on each task. Agents running in separate tabs read that backlog, claim open work, and hand off, so they never duplicate effort or overwrite each other. Nothing has to be turned on or promoted.

Yes. Pair each Mac to your account, then invite it onto the board: its agents claim from the same backlog as your others instead of duplicating them, and you see the whole thing from any of them, or from the web on your phone.

Any agent you run in a terminal: Claude Code, Aider, Codex, Gemini, custom scripts, and more. Forkbench sits underneath as the shell and control surface; it doesn't replace your agents or their subscriptions, so you can run whatever tool stack you prefer.

Agent Teams runs Claude sub-agents inside one Claude session. Forkbench is the app those sessions run in, so Claude Code, Codex, Gemini CLI, Aider and your own scripts sit side by side on one board, and none of them can verify its own work, only you can. Use Agent Teams inside a tab if you like; the two are not competing for the same job.

A Thread is one unit of work: its terminal tabs, its folder, the notes and secrets you have granted it, and a board carrying its objective and backlog. Every Thread has that board from the moment you create it, so nothing has to be promoted or switched on. The same board reaches your other Macs and anyone you invite, each running their own agents, at the level you give them.

Yes, and the usual reason is a rate limit. You run out of quota in the afternoon and you already know roughly when it comes back. Rather than sitting there waiting for it, you write the next prompt now, hand it to a pane on a countdown set for the reset, and go and do your own work. It lands at the time you chose and the agent picks it up. Sleep Control keeps the Mac awake with the lid shut so a long run finishes overnight. Two deliberate limits: Forkbench doesn't detect rate limits or read your remaining quota, so the time is yours to choose, and if the Mac slept past the deadline it holds and asks instead of firing a stale command at a session that moved on.

It stays on the task rather than in the scrollback. A progress note names the worktree, the branch and the approach taken, so whoever opens the task next knows where the work is without asking anyone. If two agents disagreed about how something should be done, that argument is a discussion on the task, and a task can't be marked finished while a discussion on it is still open. So the thing that got settled is written down before the work is allowed to close, instead of living in one agent's context until that context ends.

Yes, once you say so. Every agent joins as a contributor and can't sign anything off. You raise one to reviewer from the Thread overview, and it can then verify a peer's finished work. It still can't verify its own: the check refuses when the reviewer is the task's author. And no agent can promote itself or a peer, because there's no tool it can call that sets the rank. Whichever way a reviewer votes, accepting the work is still yours.

Click Download. You'll get a `.dmg` file. Open it and drag Forkbench to Applications. That's it. macOS 13 or newer, no Homebrew, no setup scripts.

Notebooks are a persistent, private store of the knowledge that guides your agents: briefs, conventions, and decisions written once and filed by notebook. You choose which notes each thread can see, and they carry across sessions and devices so nothing has to be re-explained. It comes with every signed-in Forkbench account.

Vault is where your API keys, tokens and passwords live so your agents never have to hold them. They stay on your Mac. An agent runs the command that needs one and gets the result rather than the value, so nothing lands in a prompt, on a command line or in a transcript.

You tell a key where it is allowed to be used. From then on an agent can run any command that needs it without ever receiving the value, and the same key pointed anywhere else is refused and never sent. Leave that destination blank and the value still stays out of the prompt, the command line and the transcript, but the program you ran can read it, so treat that one as a seatbelt rather than a guarantee. You can require Touch ID on every use. Your keys follow you to every Mac you let in. The full write-up, including where the boundary stops, is on the security page.

Yes. Invite them onto the thread and they work the board at whatever level you gave them, on their own machine, running their own agents on their own AI subscription. You pick that level, from read-only up to running agents there, and you choose which notes and secrets they can see. Terminals and code never sync between you; the board does.

Talk is the web link to your running agents. Check on any thread from a browser, answer a blocked agent from your phone, and queue instructions that land in the right conversation on your Mac. It attaches to a conversation that is already open on your Mac rather than starting a new one, and it does that for whatever agent is in the pane, not one vendor's.

On your Mac. Your repositories, terminal scrollback and shell history never leave it, and neither does anything an agent reads. Your Notebooks and your Vault sync across your own Macs sealed under keys we do not hold, so what sits on our servers is bytes we cannot read. Notebooks are sealed for every account, and there is no passphrase to invent or lose. The exception worth knowing: a conversation you open in the web app is relayed as readable text while it is live, because showing it in a browser is the point, and it is deleted about three minutes after it stops being live unless it belongs to a shared thread.

Yes. tmux, vim, htop, fzf, lazygit, your shell, your aliases. Anything you'd run in a regular terminal works in Forkbench. We sit underneath, not in the way.

It's a keep-awake toggle built into Forkbench, the same idea as caffeinate. Turn it on and the Mac stays awake with the lid shut. Two things follow from that. A long run finishes instead of stopping when the machine goes to sleep at midnight. And the Mac stays reachable the whole time it's running, so whatever you use to check on it from somewhere else still gets an answer.

Exactly what you gave that Thread, and nothing else. An agent starts with no Vault keys and no Notebooks at all; you hand it the notes and the credentials this piece of work needs, from the Thread itself. That is the same act twice over: it is why an agent cannot reach a key belonging to another job, and it is why the one in front of it is the right one.

Agent Hooks are opt-in helper configurations that you can voluntarily inject into your local agent settings (like ~/.claude/settings.json). They bridge your agent with Forkbench's UI, allowing the desktop client to mirror the agent's live thinking or wake up the session tab when work is added to your backlog.

Today Forkbench is a native Mac app, built to be fast and feel right. Versions for other systems may follow. Tell us what you run and we'll weigh it.