Forkbench for GitHub Copilot CLI
The Mac terminal built for GitHub Copilot CLI
GitHub Copilot CLI brings Copilot to the terminal as the copilot command. It answers questions interactively and runs agentic modes where you delegate a task with more autonomy, and it asks for explicit trust before it touches a folder.
Forkbench is a Mac app for running GitHub Copilot CLI where the credentials a task needs are used by the command and never handed to the agent, and a Thread can be locked to its folders by the macOS kernel so nothing it starts can read outside them. Copilot's own trust prompts keep working; this bounds what there is to trust it with.
What breaks in a plain terminal
Copilot CLI asks before it touches a folder, which is a good default and a per-session one. It does not decide what is in the folder you approved. Approve the repository and the agent has whatever else is in your environment: the token you exported this morning, the .env a colleague committed once, the credentials in your home directory that no prompt mentioned. And when a task genuinely needs a token, the honest options in a plain terminal are pasting it or exporting it into a shell the agent reads.
How Forkbench runs GitHub Copilot CLI
Keys it uses and never reads
Put the token in Vault once. When Copilot runs a command that needs it, the command gets the value and the agent gets the result, so it never reaches the prompt, the command line or the transcript. Optional Touch ID on every use. This is the reason to be here.
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 it binds a build script and a dependency's install hook too, not only the agent that agreed to the trust prompt.
A pane you can cut off entirely
Seal a pane and its agent gets no notes, no keys and no board, while the shell, the files and the git panel carry on. Live in both directions, no relaunch, which is what you want for a task on code you did not write.
A real login shell, not a wrapper
Every tab is a genuine PTY, so copilot starts exactly as it does in any terminal, with your PATH, your gh auth and your shell config untouched. Forkbench does not proxy the agent or sit between it and GitHub.
Running beside the other vendors
Nothing on a task records which agent produced it, so a Copilot pane, a Claude Code pane and a Codex pane can claim from one backlog in the same Thread. Each keeps its own subscription, and each runs on your machine.
Its own branch, in one click
Give a session a fresh worktree from the git panel so it cannot touch the branch you are working on. The panel always reflects the tab you are focused on, and Forkbench never merges or rebases on its own.
Getting GitHub Copilot CLI running
- 1Install Copilot CLI from GitHub, then open a Thread on your repo in Forkbench and run copilot in a tab.
- 2Put the tokens that job needs into Vault and grant them to that Thread. Everything is deny by default until you grant it.
- 3Lock the Thread to its folders, so the boundary is enforced by the kernel rather than by a trust prompt that covers one session.
- 4Add a tab per additional agent, from any vendor, and give each a fresh worktree so they never touch the same files.
- 5Give the Thread an objective if you want them coordinating from one backlog. It is free, and it is optional.
What this does not do: Forkbench runs the copilot binary you installed and does not change how it behaves, replace your Copilot subscription, or make it better at coding. It also does not stop Copilot reading a .env already sitting in the project, because it has the same filesystem access you do until you lock the Thread's folders. Move the key into Vault and there is nothing in that file worth reading.
GitHub Copilot CLI questions
Does GitHub Copilot CLI run normally inside Forkbench?
Yes. Every Forkbench tab is a real login shell, so copilot starts the same way it does in Terminal, iTerm2 or Ghostty, with your PATH, your gh authentication and your shell config exactly as you set them up. Forkbench does not wrap the agent or route anything through its own servers.
Copilot CLI already asks before touching a folder. What does this add?
The trust prompt decides which folder the agent may work in. It does not decide what is inside that folder, and it says nothing about your environment, so an approved session still reads whatever tokens your shell holds. A folder lock is enforced by the kernel on every open rather than agreed once per session, and a key in Vault is used by the command without the agent holding the value. The prompt is consent; these are boundaries.
Can I run Copilot CLI and Claude Code in parallel on one project?
Yes, and nothing on a task records which agent produced it, so they can claim from one backlog in the same Thread and hand work to each other. Give each its own git worktree so they never edit the same files, and remember that separate worktrees still share one environment, which is the reason to move the credentials into Vault.
How does Copilot CLI use my API keys without seeing them?
Store the key in Vault. When the 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.
Running something else?
Forkbench is agent-agnostic, so any CLI agent runs in a tab. These have a page of their own: