Solutions
What Forkbench solves
The real problems of running a fleet of AI coding agents, and how Forkbench handles each.
Memory, handoff, and running more than one agent
What survives when a session ends, a different agent starts, or somebody picks the work up on another machine.
Run your AI coding agents across multiple Macs
Forkbench brings every machine paired to your account onto one Thread board, so agents on different machines claim from a single backlog and never touch the same task. What actually travels is the scope: a secret added on one machine is usable from another without the value ever being readable on either, sealed under a key Forkbench does not hold. Removing a machine rotates that key, so revocation is real rather than a delisting.
Stop parallel agents from undoing each other's work
Collisions have two causes. Give every agent its own git worktree so they edit different files and cannot overwrite each other, and put the work on a board that leases each task to one agent at a time so two never pick up the same thing. Forkbench does both in one click. The collision nobody counts is credentials: separate worktrees still share one environment, so every agent you started can read the same tokens.
Hand off tasks between AI coding agents
Forkbench's task board is a durable per-Thread file, not a chat transcript, so a task one agent writes today, with its plan and notes, can be claimed and finished tomorrow by a different agent from a different vendor entirely. The board is how agents sharing a job keep out of each other's way. What it is for is scoping the keys and notes one job needs to the agent working it.
Answer a blocked agent from your phone
Two things fix it. The app has to show which agent is waiting, and answering has to work from a browser or phone, not just the machine running the agent. Forkbench's Thread flags whichever pane is blocked, and Talk lets you answer from anywhere, for Claude Code, Codex, Gemini CLI or Aider alike. If you only ever run Claude Code, Anthropic's own Remote Control, included on paid plans, does the same for that one agent.
Stop sitting there waiting for your quota to reset
Write the prompt while you still have it in your head, hand it to a terminal pane on a countdown set for when your quota comes back, and walk away: Forkbench delivers it to that pane at the time you chose, so the agent starts the moment the limit lifts rather than whenever you next sit down.
Does Claude Code have memory between sessions?
No. Claude Code keeps no memory across sessions by itself: when a session ends its context is gone, and CLAUDE.md only carries what you remembered to write there by hand. Memory that persists has to live outside the conversation. In Forkbench each job has a Thread, so a note filed there outlives the session that wrote it, and any agent you open in that Thread, whatever the vendor, reads it on arrival.
Can two people's agents work the same backlog?
Yes. Invite someone into a Thread (the place one job's plan, notes and keys live) and their agents claim from the same board as yours, on their own machine and their own AI subscription. Only the board crosses between you: their terminals, their code and the rest of your work stay where they are.
What can a colleague see when I invite them into a Thread?
Exactly the one Thread you invited them into (that job's plan, its notes, its board) and nothing else. Your other Threads, your note library and your account Vault are never part of an invitation. Remove them and that Thread's key rotates, so what remains is unreadable to them, and Forkbench names the secrets they already had.
Show someone a dev server without deploying it
Forkbench's Live Link puts the server already running on your machine behind a temporary HTTPS address on its own hostname, so the person you invited opens the real thing, live, without you deploying, building or uploading anything. That Thread's membership is the only check behind the link.
Give someone a key they can use but not read
Check the secret into Forkbench's Vault for the Thread that person is working in, then invite them. The commands that need the value get it when they run, and the value itself never lands in their prompt, their command line or their transcript, not even before you remove them and the Thread's key rotates.
Hand an unfinished job to another person
In Forkbench, the Thread already holds what a handover document would try to reconstruct: the objective, the backlog and the notes an agent wrote along the way. Invite the colleague into it and their agents claim from the same backlog yours was already working, instead of you writing anything down for them.
What belongs in AGENTS.md, and what it cannot hold
AGENTS.md is the right home for instructions: conventions, commands, mistakes to avoid, read by most coding agents. Findings, what an agent works out mid-job and what was already tried and abandoned, belong somewhere else: they arrive after the file is written and go stale without announcing it. In Forkbench that somewhere is a Thread, where any agent can list, read and revise a note instead of growing the file.
CLAUDE.md is too big. What do you take out?
Cut the facts and keep the instructions: an instruction like the package manager or the test command is worth paying for on every session. A fact is why a module is the way it is, or what was tried and abandoned. Facts are what make the file grow and go stale without warning. Forkbench holds them as notes on the job's Thread instead, fetched only when an agent goes looking, so the file stops growing.
Does Codex read CLAUDE.md?
No. Codex reads AGENTS.md, the cross-tool convention, rather than Claude Code's CLAUDE.md, so the file does not carry by itself, though copying or symlinking it across is a minute's work. What no rename fixes is everything never written down at all: the findings, the abandoned approaches, lost when you leave the session that produced them. In Forkbench those live on the job's Thread instead, where whichever agent you open next reads them on arrival.
Keys, files and what an agent can reach
The agent reads everything in the folder it is working in. These pages are about making that harmless rather than trying to prevent it.
Stop Claude Code from reading your .env file
You cannot reliably stop an agent from reading a file already sitting in the project, so the fix is to stop the value being in the file: keep the secret in Forkbench's Vault and let the agent run the command that needs it, with the value never entering its context at all.
Does Claude Code send my code to Anthropic?
Yes. Any file Claude Code reads becomes part of the context it sends to Anthropic, and the same holds for every other agent and its own provider. No terminal can change that, because the agent makes that request itself. What a terminal does decide is the second question, which is what ELSE on your machine ends up in that context.
Why .gitignore and .claudeignore do not hide a secret
An ignore file is a request, not a boundary. It asks a tool to skip a path, and works only as far as that tool honours it, which is why agents have been reported reading .env files despite entries in both .claudeignore and .gitignore. Move the value out instead: Forkbench's Vault holds it on your machine and hands it only to the command that needs it.
An agent read my API keys. What do I do now?
Rotate the credential first and investigate afterwards. Once a value has entered an agent's context it has been transmitted to the model provider and is sitting in that conversation's history, so the only reliable remedy is to make the value worthless. Whatever you rotate it to, put it in Forkbench's Vault next, so the next agent runs the command instead of reading the key.
Claude Code prompt injection: what it can actually reach
You cannot reliably prevent prompt injection, so the useful question is what a successful one can reach. An agent can only exfiltrate what is in its context or what its credentials let it do, and both shrink when credentials sit in Forkbench's Vault instead of the context, and each Thread's grants stop at its own folders.
Claude Code permissions: limiting what it can actually touch
Bound the agent at the filesystem rather than in the prompt. Forkbench's folder lock does this through a Seatbelt profile applied when a shell starts, denying reads and writes outside the folders you allowed, inherited by every process the shell spawns. Unlike an instruction, it cannot be talked out of, and unlike a container it asks nothing of your setup.
Give an agent deploy access without giving it the credential
The agent needs the command to succeed, not the credential to be readable. Forkbench's Vault gives the command the secret and hands the agent only the outcome, so the value never enters its context, its prompt or its transcript, and a key pinned to a destination is refused anywhere else.
What happens to my keys if I lose my Mac?
Nothing you were carrying opens them. Each key is sealed to the Mac holding it, so a stolen laptop yields nothing by itself. Remove that Mac from your account and the account key rotates: what it held stops working. Forkbench's Vault has you generate a recovery code when you set it up, and that code, kept somewhere that is not a Mac, gets you back in if every Mac is gone.
How does a tool know which agent is asking for a key?
It asks the operating system, not the caller. When a command asks the Vault for a value, Forkbench resolves which pane it came from using the kernel's audit token. A process claiming to be a different pane is not believed, so a key granted to one Thread (one job's plan, notes and keys) cannot be pulled from another.
Why does my AI agent read .env even with a rule telling it not to?
Because a rule is text the model weighs, not a gate it has to pass. A line in CLAUDE.md competes with everything else in the context window, and the tool call that opens the file often happens before the model has weighed it at all. It holds until the run where it does not, which is why moving the value into Forkbench's Vault removes the question rather than answering it again.
If you only run one agent
The honest version of whether any of this applies when there is no fleet to coordinate.
The terminal itself
For when the problem still looks like a terminal problem: the setup you would have to rebuild, and tabs you cannot tell apart.
Switch terminal without rebuilding your setup
Almost nothing you are afraid of losing lives in your terminal. Your shell, prompt, aliases, functions, PATH, tmux configuration and dotfiles all belong to the shell, not the emulator, so any terminal that opens a real login shell inherits every one of them on first launch with nothing to port, Forkbench included, where tmux, vim and your aliases behave exactly as they do today.
Stop hunting through terminal tabs
The fix is to group terminal sessions by the piece of work they belong to rather than by window position, so each group carries its own folder, its own notes and its own credentials, and switching context becomes switching group instead of reading tab titles. In Forkbench that group is a Thread, so the grouping is built in rather than a habit you have to maintain.