console-status

console-status, published as Claude Console, turns one Claude Code session into a console for several projects. A pane lists every project with its state and who it is waiting on, lets you answer decisions by pressing them, dispatches work to Claude Code background agents or to Codex, and keeps Git, pull requests, CI and usage beside them. The interface is in Traditional Chinese; the README comes in English and Traditional Chinese.

What it does

• Project table. One row per project: its state (decision needed, awaiting review, running, needs sync, idle), a six-step pipeline from spec to release, when it was last updated and a Git summary. A card on top names the one thing to handle next. With the pane closed, the band above the prompt still counts each state.
• Decisions you press. Each option in a project’s card is a button, and with the action menu open, number keys answer the decisions in order. The answer goes into the prompt box; Enter sends it to the console session.
• One-key actions. Right-click a row or press m for the action menu: run the project’s verification command, sync its STATUS card, continue to the next step (it asks for a second press within six seconds), reply to an executor that stopped on a question, send a gate to review, open STATUS.md or the pull request.
• Executors. Work goes to Claude Code background agents by default. Codex can take everything or single projects, with a fallback to Claude when Codex is unusable or under a quota threshold. A project set to manual is never dispatched, and syncs can run on a cheaper model of their own.
• Git, PR and CI. Branch, ahead and behind, uncommitted line counts, stash, recent commits, and a warning when the last fetch is over a day old. A file list grouped like git status, the pull request’s review state and its failing checks; the band turns red when CI fails.
• Usage and cache. Claude’s 5-hour, weekly and per-model limits and Codex’s quota share one table, with an estimate of when the current pace runs out (an idea taken from session-meter). The band counts down the console session’s prompt cache and, once it is cold, shows what re-writing it costs at API list prices.
• Next step on Tab. The way on (a decision, a reply, a gate, a sync, a continue) waits in the empty prompt box as a dim suggestion. Unlike next-steps, it comes from the STATUS card, not from a model.
• Project mode. In a session opened inside a registered project, the band shows that project’s pipeline and the pane opens on its card.

Install

Needs Claude Code 2.1.289 or later, plus Windows or macOS, a project registry and a STATUS file in each project. gh adds pull requests and CI; the Codex executor needs Node.js, Codex Companion and a Codex account.

claude plugin marketplace add SaM-runtime/claude-console
claude plugin install console-status@claude-console

Run /console demo in any session to see the full pane with fictional data, and /console refresh to go back to live state. /console opens and closes the pane.

Real projects need two things. The registry is a Markdown table that maps project names to STATUS files, at ~/.claude/handoffs/projects-scope.md unless you set registryPath. Each STATUS file holds a block of ten lines or fewer between <!-- CARD --> and <!-- /CARD -->, with Traditional Chinese keys for the update time, state, verification command, pending decisions, next step and gate. The repository has a template and an example registry. Options are set with claude plugin configure console-status@claude-console --values-stdin, which takes a JSON object of single-line strings.

By default only a session where you ran /console runs the console, and it starts again when you resume that session. Every other session, including claude -p runs and the background executors, gets only the command guard. /console off turns the console off for a session.

How it works

Refreshing never calls a model. Every 60 seconds, or every 20 while a job runs, the mod reads the registry and each STATUS file and runs git status in each project root without taking the index lock. With gh signed in, it asks for the branch’s pull request and checks every five minutes, every minute while checks are running. claude agents --json lists the background agents. Opening a card also reads the last 64 KB of that executor’s transcript for a four-line digest of what it was doing.

Dispatching starts processes. A Claude job runs claude in background mode with a unique name and the project as its working directory; later jobs resume the saved session. It adds no permission-bypass flag, so the agent goes through the normal permission flow. A Codex job goes through Codex Companion, the codex-companion.mjs script of the installed Codex plugin. While Codex is in use, the mod also runs bundled PowerShell (Windows) or sh (macOS) scripts that check the Codex broker and read the quota. The verify action runs the CARD’s command through a shell in the project root with a five-minute timeout; a command it has not run before for that project needs a second press within ten seconds.

Model quota is spent only by what you send: a dispatch uses the executor’s quota, a decision is a prompt you submit, and a gate review sends one prompt to the console session. A prompt sent with a project selected carries that project’s state, Git lines and executor digest as extra context. Project mode adds one section to the system prompt, unchanged for the session so it does not break prompt caching.

It writes two files: ~/.claude/handoffs/dispatch.json, with the executor, model and effort you pick, and ~/.claude/handoffs/claude-sessions.json, which maps each project to its Claude session and keeps its last 20 jobs. Approved verification commands, the jobs already auto-synced and the sessions that run the console go to the plugin’s own store. The executors write the STATUS cards, and the pane never runs a release. The http.fetch call checks for updates: it reads the latest plugin.json from GitHub at load and every 30 minutes. /console update then runs claude plugin update (or git pull --ff-only in a local clone) and reloads plugins.

Command guard. Every Bash or PowerShell call passes through tool.call. A command that cannot be taken back, such as a recursive delete outside build output and caches, a force push, git reset --hard, git clean -f, a history rewrite, DROP TABLE, terraform destroy or npm publish, opens Claude Code’s question dialog even when the permission mode would run it unseen. Only the 執行一次 (run once) answer lets it through. Anything else, or no one to ask, refuses it and tells the model not to reach the same effect another way. The guard also looks inside bash -c, powershell -Command, eval and wrappers such as sudo or xargs. Set commandGuard to deny to refuse without asking, or to off.

Loop guard. When a tool call fails twice in a row with the same arguments and the same error, the second error carries a note telling the model not to try a third time, and a toast says so. loopGuard: off turns it off.

Limitations

• The author supports Windows and macOS. Linux is covered by tests, not daily use.
• Keep one console session dispatching at a time: two consoles writing claude-sessions.json in the same instant are not fully safe.
• Codex support reads the Codex plugin’s internal state files and cache layout, so a Codex plugin update can break it until console-status catches up.
• A background agent waiting on a permission prompt still has to be attached to; the pane only answers one that stopped on a question.
• The author says the pane also shows on a phone through Remote Control, with buttons in place of the clickable rows. Filling the prompt box from there still awaits testing on devices.