Pitroom

What Pitroom does

The Pitroom MCP server hands bounded repository tasks to worker CLIs so a primary coding agent can delegate routine investigation and implementation without giving up final control. Workers can read code, make scoped fixes, run tests, and review results. The returned work includes an answer, cited locations, any detected changes, and a receipt describing worker token usage and estimated savings.

Pitroom is designed for tasks where the worker can operate within explicit permissions. It does not commit, push, reset, stash, rebase, publish, use sudo, or perform bulk deletion. A worker cannot expand the permissions assigned to its run. These controls reduce risk but are not described as a security boundary.

How it works

A run uses the default model configured by the selected worker CLI; Pitroom does not hardcode a model. Workers may be started individually or as a crew, with up to 20 concurrent workers by default and a maximum of 30. A fallback chain can move to another configured worker after errors such as rate limits, quota failures, or a missing model.

For edits, isolate mode gives a worker a private copy of the current repository state, including uncommitted and untracked files. The result is returned as a patch that can be applied or discarded. Pitroom snapshots the working tree with a temporary Git index to distinguish worker edits from existing changes, without changing the user’s index, branches, or stash.

Citations such as path:line are checked against files on disk. The system also resolves citations that omit a directory when possible and avoids treating symbols such as Schema.parse:432 as file references.

Setup and configuration

Pitroom is distributed as an npm package and provides a pitroom command-line interface. The supplied material identifies quick-start usage through commands such as pitroom run, pitroom crew, and pitroom models, but does not provide a complete installation command or required environment-variable list.

Worker selection and model availability come from the worker CLIs. The models command reports available workers, supported effort levels, configured costs, and usage. Run records are stored under ~/.local/state/pitroom; the project does not create a .pitroom/ directory, modify .gitignore, or create branches.

Tools and capabilities

The Pitroom MCP server’s documented CLI capabilities include:

• run for a single bounded task.
• crew for starting multiple workers.
• watch --json for streaming changes as one JSON line per update.
• wait -g for collecting a group’s answers.
• apply for landing an isolated patch, with deletion requiring --allow-delete.
• discard for abandoning an isolated result.
• revert <id> for undoing a worker’s recorded changes.
• dash for a local run dashboard with task, steps, results, diffs, history, and statistics.
• history for searching previous runs.
• savings --card card.svg for generating a shareable receipt card.

Workers can be assigned read-only, isolated-copy, in-place-edit, or web permissions. Web access is not enabled unless requested. pitroom watch --json and grouped commands support workflows where the primary agent follows several workers while continuing its own work.

Limitations and notes

Pitroom depends on the worker CLIs and their configured models. The README names OpenCode, Codex CLI, Claude Code, Gemini CLI, Qwen Code, and Kilo Code as worker options, but availability, pricing, free tiers, quotas, and effort levels depend on those tools and their configuration. Parallel writers are refused, while read and review work can run concurrently.

The documented safeguards are intended to constrain normal worker behavior, not to replace a security boundary. Isolated patches can be applied only after checks, and deletion is refused unless explicitly allowed. The provided material does not document a dedicated MCP transport, required environment variables, or client-specific installation steps.