Forkbench for Codex CLI

The Mac terminal built for Codex CLI

Codex CLI is OpenAI's terminal coding agent, which reads your repository, proposes changes and runs commands from the command line.

Forkbench is a Mac app for running OpenAI's Codex CLI where a key in Vault reaches the command that needs it and never the agent, and a Thread can be locked to its folders by the macOS kernel. Codex keeps applying its own sandbox inside, because Forkbench bounds the shell it starts in rather than wrapping the pane, and Seatbelt profiles do not nest. Each session gets a real login shell and its own git worktree in a click.

What breaks in a plain terminal

Most people who run Codex CLI also run something else, because the agents are good at different things. That is where a plain terminal stops helping. Each agent keeps its own memory in its own format, so what Codex worked out this morning is invisible to whatever you open this afternoon, and you end up re-explaining the same project twice a day. Add the usual problems of running several sessions at once, tabs that look identical and agents editing the same files, and the coordination becomes your job.

How Forkbench runs Codex CLI

Keys it can use and never read

A key in Vault reaches the one command that needs it, so Codex gets the result of a push or an API call without the token entering its context. 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

codex launches in a genuine PTY with your shell config and aliases intact. Forkbench does not wrap it, proxy it or sit between it and OpenAI.

Built for running two vendors on purpose

Nothing on a task records which agent wrote it. Codex can claim a task Claude Code planned, read the notes and the discussion that settled a question, and finish it. That is the point of the board, not a side effect.

One brief, not one per vendor

Notebooks hold your conventions and decisions once. Grant a note to a Thread and every agent in it reads the same brief, instead of you maintaining a separate memory file per vendor.

Its own branch, in one click

A fresh worktree from the git panel keeps a Codex session off your working branch. The panel reflects the focused tab, and Forkbench never merges or rebases on its own.

Work that survives the session

The board is written to disk as it changes. Close the pane, quit, or reboot, and the plan, the progress notes and the blockers are still there.

Getting Codex CLI running

  1. 1Open a Thread on your repo and run codex in a tab, exactly as you would in any terminal.
  2. 2Open a second tab for Claude Code or Gemini CLI in the same Thread, so both work from one board.
  3. 3Give any tab a fresh worktree from the git panel to keep its edits off your working branch.
  4. 4Give the Thread an objective. Agents add tasks, claim them, and hand off when they hit something another one is better at.
  5. 5Accept the work when an agent reports it finished. That acceptance is what makes it done and unblocks anything waiting on it.

What this does not do: Forkbench does not improve Codex CLI's output or replace your OpenAI subscription. It runs the same binary and bills nothing per request.

Codex CLI questions

Running something else?

Forkbench is agent-agnostic, so any CLI agent runs in a tab. These have a page of their own: