Kibitz: A Decoded Feed and Dispatcher for Claude Code and Codex Sessions

The problem Kibitz targets: too many agent terminals, no single readout

Running one Claude Code or Codex session is manageable in a terminal. Running four is not, because each session keeps its own scrollback and its own prompt line, and nothing tells you which one is waiting, which one just finished, and which one has gone quiet. Kibitz addresses that by watching sessions and producing a live commentary feed, then letting you send a prompt into any session it is watching from one composer. The audience is narrow: developers who keep multiple agent CLI sessions open at once, on macOS or Windows, inside VS Code or a terminal. If you run one session at a time, the extension adds a panel you will not read. The README frames the second half of the problem as coordination, which in practice means dispatching a prompt to session 3 without alt-tabbing to find which terminal window session 3 lives in.

How the watcher, the feed, and the dispatcher fit together

The moving parts are a watcher, a commentary generator, and a dispatcher, exposed through two front ends: a VS Code panel and a terminal CLI. The watcher tracks active sessions from both providers, and the README describes targeting as limited to active sessions in the watcher window, meaning sessions with recent activity. That window is the boundary of everything Kibitz can do; a session that has gone cold is not a valid target. The commentary layer produces the live feed. The dispatcher takes a prompt plus a target and emits status events as the send progresses: queued, started, sent, failed. Those four states are the honest part of the design, because they distinguish a prompt that was accepted from one that actually reached a session. Model handling is provider-aware, so the extension does not assume the same model identifiers apply to Claude and Codex. The README does not describe the transport between the extension and the provider CLIs, so how a dispatched prompt physically reaches a running session is not something I can confirm from the supplied material.

Installing the extension and the CLI

Two install paths exist and they are independent. The VS Code extension comes from the Marketplace under the identifier kibitzsh.kibitz, or by searching Kibitz in the Extensions panel. The CLI comes from Homebrew with brew install kibitzsh/tap/kibitz on macOS or Linux, or from npm with npm install -g @kibitzsh/kibitz. Building from source needs Node.js 20 or newer, npm 10 or newer, VS Code 1.85 or newer, and at least one provider CLI installed and authenticated, either codex or claude. The build is npm ci followed by npm run build. To install the built extension into a local VS Code or Cursor, npm run deploy:vscode copies dist/ and package.json into your local extensions directory and replaces older Kibitz extension folders. To run the CLI from source, build and then run node dist/cli/index.js. The npm package points bin.kibitz at dist/cli/index.js, so a global install exposes the kibitz command.

Composer controls and the dispatch contract

In the VS Code panel, target badges always include /1 for a new session on the current provider and /2 through /N for existing active sessions from the watcher list. You select a target by clicking a badge, by typing /N to select only, or by typing /N <prompt> or N/ <prompt> to select and send in one step. Plain text without a target token goes to whatever target is currently selected. Starting a new terminal session is one step: pick /1 and send. The CLI mirrors this with slash commands rather than badges. /sessions lists active sessions with numeric indexes, /target <index|agent:sessionId|new-codex|new-claude> sets the destination, /interval <15s|30s|1m|5m|15m|1h> sets summary cadence, and /update checks for updates. The composer also accepts /help, /pause, /resume, /clear, /focus, /model, and /preset. Every send prints or emits one of queued, started, sent, or failed, in both front ends. The two-step pattern in the CLI, set target then send plain text, is worth internalizing, because a prompt sent before you set a target goes to the previously selected one.

Where Kibitz stops: watcher scope, no broadcast, and best-effort Linux

The README states two scope limits directly. Targeting is limited to active sessions in the watcher window, so you cannot address a session that has been idle long enough to drop out of it. Multi-target broadcast in one send is not implemented, which means fanning one prompt out to five sessions is five sends. The compatibility matrix is a contract, and it lists Linux as best effort for both the VS Code panel and the terminal CLI, while macOS and Windows are supported for both. If Linux is your primary environment, that row is the honest signal. There is also a scheduling detail in the release tooling worth knowing: the daily download digest workflow runs at 9:00 AM PT with a UTC cron plus a PT hour guard, which is a fragile pattern around daylight saving changes. That affects the maintainer's telemetry emails, not your sessions, but it is the kind of thing that quietly stops firing. Finally, the README does not document what happens to a queued prompt if the target session exits between queue and send, beyond the failed status.

How it differs from tmux plus a terminal multiplexer

The closest thing most people already have is tmux or a terminal split layout. The difference in approach is what gets summarized. A multiplexer shows you raw scrollback from each pane and leaves interpretation to you; you still read four streams of tool calls and diffs to work out which agent is stuck. Kibitz generates commentary over the sessions and renders a single feed, so the reading is done for you and the raw terminal stays available underneath. The trade is control and portability. tmux runs anywhere a terminal runs, including remote hosts over SSH, and it has no opinion about which agent CLI you use. Kibitz is tied to Claude Code and Codex, needs VS Code 1.85 or newer for the panel, and its targeting only reaches sessions inside the watcher window. If your agents run on a remote box, the multiplexer approach does not care and Kibitz's local watcher model is a real constraint, though the README does not state whether remote sessions are in scope.

Maintenance surface and what the MIT licence leaves you

The repository ships a guarded release flow. npm run cr performs checks and a build, bumps the version, publishes to the VS Code Marketplace and npm, verifies versions, updates the Homebrew formula, and pushes tags. That single command depends on three repository secrets: VSCE_PAT for Marketplace publishing, NPM_TOKEN for npm, and HOMEBREW_TAP_TOKEN with write access to kibitzsh/homebrew-kibitz. The download digest workflow needs RESEND_API_KEY and a read-scoped HOMEBREW_TAP_TOKEN, with the sender fixed to stats@kibitz.sh and the recipient fixed to a personal address. For a user, the upgrade cost is low: the extension updates through the Marketplace, and the CLI through npm or brew. For a fork, the cost is concentrated in those secrets and in the fixed email addresses, which you would have to replace before any of the release automation works. The licence is MIT, which permits commercial and closed-source use and modification provided the copyright notice and permission notice are retained; that is a summary of the licence text, not legal advice, and you should read LICENSE in the repository for the binding terms. There is no separate enterprise or hosted tier mentioned in the material, so there is nothing to negotiate.

Editorial conclusion

Adopt Kibitz if you already run several Claude Code or Codex terminals on macOS or Windows and want one place to read their activity and push prompts into them. Skip it if you need broadcast to many sessions at once, if you run Linux as a first-class target, or if you want a hosted dashboard, since the compatibility matrix lists Linux as best effort and the README states multi-target broadcast in one send is not implemented. Before relying on it, run npm run typecheck and npm run check:compat against your Node and VS Code versions, and confirm that your provider CLI is installed and authenticated as either codex or claude on PATH.

Official sources

1. kibitzsh/kibitz on GitHub
2. License: MIT
3. Project website
4. README
5. Releases