Run Claude Code, Codex CLI and Gemini CLI side by side on a Mac

All three ship as command-line tools for macOS. Pick one install method per tool; the commands below are the ones each project documents.

Claude Code

curl -fsSL https://claude.ai/install.sh | bash   # native installer, auto-updates
brew install --cask claude-code                  # or Homebrew
npm install -g @anthropic-ai/claude-code         # or npm (Node 22 or later)
claude --version

Codex CLI

npm install -g @openai/codex
brew install --cask codex                        # or Homebrew

Gemini CLI

npm install -g @google/gemini-cli
brew install gemini-cli                          # or Homebrew
npx @google/gemini-cli                           # or run without installing

Hypervibe runs whatever binaries are already on your PATH, so this step is the same whether you end up in tabs, tmux or on the board.

None of the three needs an API key for interactive use. Each one signs in through the browser with the plan you have:

Each tool keeps its own state directory, so they never share sessions or logins. That is also why each can have its own project instructions file: CLAUDE.md for Claude Code, AGENTS.md for Codex, GEMINI.md for Gemini CLI. Keep the shared facts about the repo in one of them and point the others at it, rather than maintaining three copies.

Three agents writing into one working tree will overwrite each other. Two arrangements avoid it.

One worktree per writing agent

Git worktrees give each agent its own checkout and branch of the same repository. Claude Code can create one for itself; for the others, create it with git and start the CLI inside:

claude --worktree api-cleanup                    # Claude Code creates .claude/worktrees/api-cleanup

git worktree add ../shop-codex -b codex-migration
cd ../shop-codex && codex                       # Codex in its own checkout

git worktree add ../shop-gemini -b gemini-docs
cd ../shop-gemini && gemini                     # Gemini CLI in its own checkout

Branches merge back through normal git. Dependencies are installed per worktree, so budget disk for it.

Split by role instead of by files

If only one agent writes, the others can share its checkout. A common split: one implements, a second reviews the diff as it lands, a third writes the docs or the tests from the same tree. Read-only roles do not collide. Ask the reviewer to work from git diff, which every agent reads the same way.

With tabs or tmux you can run all three today; the parallel sessions guide covers both in detail. The limits are the same as with one CLI, only sooner: you cannot see which agent is waiting, everything closes with the terminal, and nothing helps a task move from one agent to another.

On a Hypervibe board, each CLI gets a console that is the real interactive tool in a real terminal, signed in with the account you set up above. The board adds what three different vendors' tools will never add for each other:

• One status language for all of them. The mission map reads each CLI's own hooks and shows every console as working, resting or needing you.
• Handoffs with state. "Pass this to codex" summarizes the outgoing Claude Code session and lands the brief on the Codex console as a prepared prompt. You press Enter.
• @-mentions and voice to direct a command at one console. Say it or type it; the prompt is prepared, never sent for you.
• Resume for all three on reopen, each through its own CLI's native mechanism.
• Usage per CLI in one place, so you can see which subscription is close to its limit before it stops you mid-task.

The agents do not share a conversation, so the handoff has to travel through something they all read: files and git. The manual version works anywhere.

1. Ask the outgoing agent to write a short brief to a file: what changed, what is left, how to verify. HANDOFF.md in the repo root is fine.
2. Commit or at least stage the work so the diff is inspectable.
3. Start the next agent in the same tree and point it at the file and at git diff.

Hypervibe's handoff does these steps for you and keeps you in control of the last one: the outgoing session is summarized, the brief lands on the new agent, and nothing is sent until you press Enter.

Deciding which agent gets which job

Rather than trusting a ranking, run the same task in two consoles once and compare the diffs. Keep the one whose plan you would have written yourself, and use the other as the reviewer for that class of task. Repeat when the tools update, which is often.