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.
Updated
People pick OpenCode specifically to avoid being tied to one model vendor, and then run it in a terminal that ties them to one session instead: the plan lives in that session's scrollback, so switching model or agent means re-explaining the project. Forkbench keeps the plan on a board any agent can read, with no vendor recorded on a task, and a provider key in Vault that reaches only the command that needs it.
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 machine and gives it only to the command that needs it, so it never enters the prompt or the transcript. Vault is free.
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 is free too; it needs a signed-in account and nothing more.
Running something else?
Forkbench is agent-agnostic, so any CLI agent runs in a tab. These have a page of their own: