CRAB: clean-room rebuild from behavior
CRAB
MCP servers that observe an app as a black box and rebuild a feature from a behavioral spec, with no access to the original code
- 310 ★ on the repository
- Last commit
- Apache-2.0
Broad access
Why this level
- A dual-use tool: it studies third-party apps and reproduces their behavior, and the right to observe is set by product terms and law
- It runs targets in Docker, drives a browser and an Android device over `adb`, and passes a Claude token to the clean-room container
Install
- Works in
Manual install
uv tool install "crab-cleanroom[web]"Needs Python 3.12 or newer; the command is `crab`. For web targets run `crab install-browser` next.
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- A dual-use tool: it studies third-party apps and reproduces their behavior, and the right to observe is set by product terms and law
- It runs targets in Docker, drives a browser and an Android device over `adb`, and passes a Claude token to the clean-room container
This is third-party code. Review the repository files before installing.
What it does
CRAB stands for Clean Rebuild of Anything's Behavior. Work is split between two agents. The observer studies the target app as a black box: what it accepts and rejects, which defaults it applies, how it behaves at the edges and in what order it shows screens. CRAB turns those observations into testable rules, checks them against the original and releases a sanitized spec. The second agent, the clean implementer, sees only the spec and writes its own implementation. It asks the gate to compare against the original and gets back only abstract pass or fail verdicts. Code, decompilation and stack traces are not captured: whatever cannot be seen from outside is recorded as an explicit unknown. The observer connects to the agent as the `crab observe` MCP server, and the `observe_target` prompt sets the working order. Three kinds of targets are supported: command-line tools, web apps through Playwright and Android apps through `adb`. Every release is checked for copied expression and real names, and the audit log is signed and hash-chained.
Who it is for. Teams that need their own version of a third-party product feature while legal requires a clean-room process with an observation record and separated roles.
Good fit when
- A competitor's feature is clear from behavior while the source is unavailable or off limits
- An old internal tool has lost its code and its behavior has to be reproduced from a spec
- A command-line tool or web app is rewritten on another stack and the result is checked with hidden tests
- Legal wants a record: what was observed, what entered the spec and who approved it
- An Android app is being analyzed with an emulator or a device over `adb`
Not a fit when
- The goal is to bypass CAPTCHAs, bot protection, root checks or app signature tampering: CRAB refuses such actions and the refusals are not configurable
- You need code or binary analysis: the tool deliberately does not capture the implementation
- The target runs on macOS, Windows or iOS: support there has not started
- The app's terms of use do not allow observing it
Example request
Open web:http://localhost:3000/ as a research target and follow the observe_target playbook: discover the UI, probe every field, inject API faults, state rules and release the spec.MCP
- Transport
- stdio, http
- Authentication
- not required
Limitations
The project is early software, version 0.4. The purpose of each analysis is declared at intake and the legal assessment belongs to the user.
Command-line tools are marked stable, web and Android targets working, Linux desktop experimental. Command-line targets need Docker, web needs Chromium through Playwright, Android needs the SDK and an emulator or a device.
Python 3.12 or newer is required. Until version 0.3 the project was called Teardown: the `teardown` command and `TEARDOWN_*` variables still work. The repository's last commit is from November 2026.
How to disable. Remove the server with `claude mcp remove crab-observe`. The tool itself is removed with `uv tool uninstall crab-cleanroom`; project data stays in the project directory.
FAQ
How do I connect CRAB to Claude Code?
Install the package, then run `claude mcp add crab-observe -- crab observe --project /path/to/project`. Any MCP client works: the server runs over stdio and over HTTP with the `--port` flag.
What is the clean room in CRAB?
Two containers with different permissions. The observer reaches the target only through CRAB drivers, the implementer sees a single directory with the spec. Every crossing goes through the gate and into the log.
Who approves a spec release?
In strict mode a release needs approval at a terminal through `crab approve`. The observer's tools cannot approve anything. In practice that is a few class-level decisions per release.
What does CRAB never do?
It never bypasses CAPTCHAs and bot protection, root or attestation checks, or FLAG_SECURE, flips Electron fuses or re-signs binaries, uses fake accounts or exceeds configured rate limits. It captures no code bodies, decompilation or stack traces. These refusals are not configurable.
Which targets does CRAB handle?
Command-line tools (stable), web apps and Android apps (working), Linux desktop (experimental). macOS, Windows and iOS have not started. For web the author reports 96.9–99.2% of hidden tests on the last three held-out apps.
Discussion
No questions or reviews yet.
Related
MCP serversAn open-source Rust terminal agent: any model from DeepSeek to Bedrock, layered settings and allow and deny permission lists.
An MCP server that builds a code graph once and serves the answer to the agent instead of re-reading files
Gives the agent an understanding of your repository: it indexes the code and answers questions about it in Claude Code, Cursor, Codex, Windsurf and more
A dependency-free CLI and MCP server that builds a call graph of a repository so the agent understands code without reading whole files
A CLI and MCP server that build a code graph with Tree-sitter so an agent reads only needed functions in review, saving tokens
A skill and CLI for code review: a team of reviewer agents inspects changes independently, debates findings and produces one report
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| CRAB: clean-room rebuild from behavior (this card) | no | not required | 310 | |
| Reverse API Engineer | no | 3,502 | recovers an API from network traffic and does not write an implementation from a spec | |
| Playwright MCP | yes | not required | 39,570 | drives a browser, with no rules, gate or sanitized spec |
README in short
The README follows the cycle: observe, generalize, gate, rebuild. Results were scored on hidden test suites, and the method is described in `docs/evaluation.md`. The responsible-use section lists what CRAB never does under any settings.