Set boundaries for AI agents and your team.
Supervise everything. Safeguard your work.

Forkbench is the ultimate desktop app for running AI coding agents with total control. Lock each job to its folders with the macOS kernel, let agents use API keys they can never read, and see at a glance who is working and who needs you. Share one job with anyone without sharing your machine, and nothing counts as done until you accept it.

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.

It is the best way to vibe code without the fear. Lock the Thread to your project folders, drop your keys in the Vault, and let the agent rip. You watch everything from one window and accept the result only when it is right.

Absolutely. The Squad setting on each Thread decides whether agents may open helper terminals, which agent every helper runs as, and whether any of them can reach your other machines. You set the rules and the squad follows them.

Yes. Live Link puts your local dev server behind a temporary HTTPS link that only people invited to that Thread can open. Show off what the agent built in seconds, with no deploy and no public tunnel.

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 machine 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.

No. Your agent does the heavy typing, and everything around it has a button: write commands and prompts in a real editor in the bottom sheet, star your favourite prompts and commands and pick them from a searchable shelf alongside your history, jump between folders from a bar, stage and commit from the git panel, and drop files straight onto the terminal. A guided tour shows you around on day one, and a red flag tells you when an agent needs your answer.

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. It is fast, with tabs, split panes, search across the whole scrollback, and ssh and tmux working in any pane. On top of that it 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.

Forkbench, and it is free. Two things decide it. How many you run: 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.

Put them in one Thread with a goal and watch them go. Each agent claims a task you can see beside its tab, a live pulse shows who is busy, and a stuck agent turns red so you unblock it first. A task counts as done only when 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 machine 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 machines 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 machine 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 machine 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 machine. 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 machine 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.

No. Inviting somebody onto a Thread gives them that Thread and nothing else: its notes, its keys, its board. Your account's Vault and your note library are never wrapped to another person, so they cannot open a Thread you did not invite them to. Take them off it and what they could reach stops working.

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 desktop. It attaches to a conversation that is already open on your machine rather than starting a new one, and it does that for whatever agent is in the pane, not one vendor's.

On your own machine. 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 machines 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 machine 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 machine 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.

Both are being built. Today the Mac build is the one you can download, and it is the only one: there is no Windows or Linux binary yet and we would rather say so than put a button on a file that does not exist. Leave your address on the download page and you get one email on the day your platform is out, and nothing before it.