Forkbench for Cursor CLI
The Mac terminal built for Cursor CLI
Cursor CLI is Cursor's coding agent in the terminal, installed with a one-line script and run as agent. It works interactively or headless with -p for scripts and CI, and it is included with every Cursor plan.
Forkbench is a Mac app for running Cursor CLI, and what it changes is what an agent can reach: a key it uses without ever holding the value, and a set of folders it cannot read outside of, enforced by the macOS kernel. Around that, each agent gets a real login shell in its own tab and a Thread that holds the folder, the notes and the keys that belong to one job. Your editor is untouched, whether that is Cursor, Neovim or anything else.
What breaks in a plain terminal
Cursor CLI is easy to run and easy to run several of. That is where it gets awkward, and the awkwardness is not Cursor's fault. Tabs stop being distinguishable once there are six. Two agents on the same checkout undo each other, so you end up hand-rolling worktrees. Whatever an agent worked out lives in scrollback, and closing the pane takes it. And the moment one of them needs to push, deploy or call a paid API, the options are pasting a token or exporting it into a shell every one of those agents can read.
How Forkbench runs Cursor CLI
Keys it uses and never reads
Store the token in Vault once. When an agent needs to push or call an API, the command runs with the value and the agent takes only the result. The key never appears in the prompt, the command line or the transcript. Optional Touch ID on every use. This is the reason to be here; everything below is what makes it usable.
Folders it cannot wander out of
Lock a Thread to the folders the job is about. Every shell in it starts under a macOS Seatbelt profile the kernel enforces and every process inherits, so a delete that is right inside the repo and wrong one level up hits a wall. Builds still run, and the network is untouched.
A pane you can cut off entirely
Handling an unfamiliar dependency or a strange issue? Seal that pane off from its Thread and its agent gets no notes, no keys and no board, while the shell, the files and the git panel carry on exactly as before. Live in both directions, no relaunch.
A real login shell, not a wrapper
Every tab is a genuine PTY, so agent starts exactly as it does in any terminal, with your PATH, your shell config and your Cursor settings untouched. Forkbench does not proxy the agent or sit between it and Cursor.
Parallel agents that stay apart
Open a tab per agent and give each one a fresh worktree from the git panel in a click, so two never edit the same files. They share the Thread's objective and backlog while working in separate directories on separate branches.
One backlog, whichever agent shows up
Nothing on a task records which agent wrote it, so work a Cursor CLI agent planned this morning is claimable by a Claude Code or Codex pane this afternoon. The board and the notes are free, and they are there because agents working one job need somewhere to coordinate, not because they are what you came for.
Headless runs that still leave a trace
Running agent -p in a script is fine here. The task, its progress notes and its blockers are on the Thread's board rather than in output nobody kept, so an unattended run leaves something a person or the next agent can read.
Your editor stays yours
Forkbench does not replace Cursor, VS Code or Neovim, and it has no editor of its own. It is where the agents run and what they are allowed to reach, alongside whatever you edit in.
Getting Cursor CLI running
- 1Install Cursor CLI with the one-line script from Cursor, then open a Thread on your repo in Forkbench and run agent in a tab.
- 2Put the token the job needs into Vault, and grant it to that Thread. Everything is deny by default until you grant it, so no other job has it.
- 3Lock the Thread to its folders, so the boundary is enforced by the kernel rather than by a line in a config file the agent may or may not honour.
- 4Add a tab per additional agent, and give each a fresh worktree from the git panel so they never touch the same files.
- 5Give the Thread an objective if you want the agents coordinating from one backlog. It is free, and it is optional.
What this does not do: Cursor CLI is in beta and moves quickly, and Forkbench runs whatever version you installed. Forkbench does not replace the Cursor editor or your Cursor subscription, and it does not make the agent better at coding. It changes where the work is recorded, what the agent can reach, and what is still there tomorrow. Cursor 3 also ships its own Agents Window and worktree isolation inside the editor, so if everything you run is Cursor and you live in that editor, start there and come here when the credential and cross-vendor parts start to matter.
Cursor CLI questions
Can I run Cursor CLI agents in parallel?
Yes. Open a tab per agent and give each one its own git worktree in a click, so they work on separate branches in separate directories and never edit the same file at once. They still share one objective and one backlog, claiming tasks under a lease so no two pick up the same work. Closing a pane releases the claim immediately and leaves the plan on the board.
Does Cursor CLI run normally inside Forkbench?
Yes. Every Forkbench tab is a real login shell, so agent starts the same way it does in Terminal, iTerm2 or Ghostty, with your PATH, shell config and Cursor settings exactly as you set them up. Forkbench does not wrap the agent or route anything through its own servers. Headless runs with -p work the same way.
Is this a replacement for the Cursor editor?
No, and it has no editor of its own. Forkbench is where terminal agents run and what they are allowed to reach. People commonly keep editing in Cursor, VS Code or Neovim and use Forkbench for the agents, the board and the keys. Cursor 3 also has an Agents Window and worktree isolation of its own, which is the better starting point if everything you run is Cursor.
How does Cursor CLI use my API keys without seeing them?
Put the key in Vault. When an agent runs a command that needs it, the command receives the value and the agent receives the result, so the key stays out of the prompt, the command line and the transcript. Bind the key to a destination and the same key aimed anywhere else is refused and never sent. It is containment rather than a guarantee: a command you authorised can still print what it was handed.
Can Cursor CLI and Claude Code work on the same project together?
Yes, and that is the normal case here. Nothing on a task records which agent produced it, so a Cursor CLI pane and a Claude Code pane in the same Thread claim from one backlog, read the same notes, and hand work to each other. Each keeps its own vendor subscription and runs on your machine.
Running something else?
Forkbench is agent-agnostic, so any CLI agent runs in a tab. These have a page of their own: