Forkbench for OpenCode
The Mac terminal built for OpenCode
OpenCode is an open-source terminal coding agent that works with a range of model providers rather than being tied to one vendor.
Forkbench is a Mac app for running OpenCode where the provider keys it needs are used by the command and never reach the agent, and a Thread can be locked to its folders by the macOS kernel. It gets a real login shell in its own tab, and the free task board it works from records no vendor on a task, so any other agent can pick the work up.
What breaks in a plain terminal
People choose OpenCode partly to avoid being locked to one vendor, and then run it in a terminal that has no opinion about any of this. The result is the lock-in reappearing one level up: the plan lives in one session's scrollback, so switching model or agent means explaining the project again. Running several sessions brings the usual collisions, and the provider keys have to sit somewhere the process can read.
How Forkbench runs OpenCode
Provider keys it can use and never read
Vault keeps the key on your Mac and gives it only to the command that needs it, so it never enters the prompt or the transcript. Vault is part of Pro.
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 that the kernel enforces and every process inherits, including build scripts and a dependency's install hook, so a read or a delete outside them is refused rather than discouraged. Builds still run, paths still resolve, and the network is untouched.
A real login shell
opencode launches in a genuine PTY with your shell config and provider settings intact. Nothing is wrapped or proxied.
Vendor-agnostic all the way down
No task on the board records which agent wrote it, so OpenCode, Claude Code and Codex claim from one backlog and hand off to each other without anything being re-explained.
Parallel sessions that do not collide
One click gives a tab a fresh worktree, and the board leases each task to one agent, so two sessions never edit the same tree or pick up the same work.
A brief that outlives the session
Notebooks hold the conventions and decisions once, granted per Thread, and the board keeps the plan on disk through a pane close, a quit and a reboot.
Getting OpenCode running
- 1Open a Thread on your repo and run opencode in a tab.
- 2Store your provider keys in Vault and grant them to the Thread, so they stay out of your shell profile.
- 3Give the Thread an objective so the agents share one backlog instead of duplicating each other.
- 4Add a tab for a different agent when one is better suited, and let it claim the open task.
- 5Accept work when an agent reports it finished. That acceptance is what makes it done.
OpenCode questions
Does OpenCode run normally inside Forkbench?
Yes. Each tab is a real login shell, so opencode behaves exactly as it does in any terminal, with your configuration and model provider settings unchanged.
Can OpenCode share work with Claude Code or Codex?
Yes. Nothing on a task records which agent wrote it, so all of them claim from the same Thread board and hand off with the notes and discussion still attached.
Where do my model provider keys live?
In Vault. A key reaches the single command that needs it, so it never enters the agent's prompt, the command line or the transcript. OpenCode still has the filesystem access you do, so a key left in a .env file is still reachable. Move it into Vault and there is nothing left in that file to read.
What does it cost to run OpenCode in Forkbench?
Nothing extra for the agent. OpenCode stays on whichever provider you configure, and Forkbench never meters requests. The terminal, your notebooks and a board on every Thread are free. Vault and running more than one agent on the same board are Pro, and every account starts with 30 days of it without a card.
Running something else?
Forkbench is agent-agnostic, so any CLI agent runs in a tab. These have a page of their own: