Clawpatch borrows your installed coding agent, keeps every record under .clawpatch, and stops before it commits

The provider is your coding agent, and clawpatch never calls a model API

The provider section is explicit about the boundary. The default provider is the local Codex CLI. Beyond that, Clawpatch integrates ACP-compatible agents through ACPX, and ships adapters for Claude Code, Grok Build, OpenCode, Pi, and an experimental Cursor Agent path. Providers are installed coding harnesses or agent CLIs, and the sentence that matters is that Clawpatch does not call model APIs directly: authentication, model transport and agent execution all stay with the harness you selected. That also means the review quality is a property of your provider and its permissions, not of this tool, and the tree reflects the seriousness of that arrangement with a `VISION.md` described as the project boundary plus a `SECURITY.md` and an `agents/` directory. The docs point at a safety guide before you use write-capable providers on untrusted code, on the grounds that provider sandboxes and tool restrictions differ.

fix refuses a dirty worktree, and open-pr is a separate command

The safety rules are about who does what. Clawpatch requests read-only provider execution for review and revalidation. The repair step is `clawpatch fix --finding <id>`, which needs an explicit finding ID, refuses a dirty source worktree by default, records the changed files and the validation results, and does not commit or push anything. Creating a commit and a pull request is a different command, `clawpatch open-pr --patch <id>`, which commits the recorded patch files, pushes a branch, and opens the pull request. Clawpatch does not merge changes. That split means a review pass cannot wander into your working tree, a repair is always tied to one finding you chose, and the irreversible step is something you invoke on purpose with the patch id in hand. Re-checking a finding against current code is a third command again, `clawpatch revalidate --finding <id>`, so the loop is review, inspect, repair, confirm.

Mapping is deterministic by default and skips two kinds of directory

The map stage is the part that decides what gets reviewed. Clawpatch detects reviewable boundaries across Node.js and TypeScript, Python, Ruby, PHP, Go, Rust, C and C++, Java and Kotlin, .NET, and Swift projects, using manifests, framework conventions, routes, packages, targets, tests, and nearby context. Two exclusions are stated up front: generated directories and symlinked directories are skipped. By default the mapping is deterministic, which means the same repository produces the same feature records, and the default mapper inspects repository structure without calling a model at all, so `clawpatch init`, `clawpatch map` and `clawpatch status` work before any agent is configured. Two flags change that: `--source auto` and `--source agent` add provider-assisted slices when a repository needs deeper interpretation. So the honest description is a deterministic structural mapper with an opt-in model layer, not an agent that studies your architecture.

Everything persists under .clawpatch, and stdout is reserved for machines

Initialization creates project-local state under `.clawpatch/`, and that directory is where configuration, feature records, findings, patch attempts, reports, and run history all live. The output contract is split the same way: commands that support `--json` keep machine-readable results on stdout and send human progress to stderr, and review progress goes to stderr too. That split is what makes the tool composable in CI, and there is a dedicated command for it, `clawpatch ci --since origin/main --output clawpatch-report.md`, described as the source-read-only init, map, review, and report loop. The resumability claim follows from the same design: because findings and run records stay on disk, an interrupted run resumes instead of starting over. Configuration itself can set include and exclude paths, provider defaults, context limits, and validation commands, so the scope of what gets reviewed and what counts as a passing fix are both declared rather than hardcoded.

Three runtime dependencies, and two scripts that do the same thing

The dependency list is short enough to read in one pass: `js-tokens` at ^10.0.0, `proper-lockfile` at ^4.1.2, and `zod` at ^4.6.5. The lock comes from proper-lockfile, the schema validation from zod. Everything else is development tooling: oxlint with its own `oxlint.json` config, oxfmt for formatting with `.oxfmtrc.json`, TypeScript at ^7.0.2, and Vitest 5 with the V8 coverage provider. Two scripts in the manifest do exactly the same thing, since both `check:changed` and `test:changed` resolve to `pnpm run test`, which makes the first name misleading. The build removes `dist` with a small node one-liner before running `tsc -p tsconfig.build.json`, `prepack` runs the build, and the published package exposes `dist/cli.js` as the `clawpatch` binary while shipping only `dist`, the README, `VISION.md` and the licence.

Node 22 for the CLI, three majors in continuous integration

The engine field asks for Node 22 or newer, and the install instructions offer both package managers:

pnpm add -g clawpatch

npm install -g clawpatch

Development is narrower than that: the file asks for Node.js 22.x with 22.13 or newer, 24.x, or 26+, using the pnpm version declared in the manifest, which is pinned with a full integrity hash rather than a bare version string. Continuous integration tests Node.js 22, 24, and 26, while the published CLI keeps supporting Node 22 or newer, so a user on the floor of the range and a developer on the top of it are both covered. The coverage script runs the full suite with V8 coverage, prints a text report, and writes both a JSON summary and an HTML report into `coverage/`. There are also two smoke scripts beyond tests, one for the package and one for the site, which is the `website/` directory in the tree.

Three descriptions of the product, and a crabbox config with no dependency behind it

The same tool describes itself three ways. The repository description is Review code. Patch bugs. Land PRs. The manifest description is Automated code review that lands fixes. The README heading is Review by feature, fix by finding. The third is the only one that describes the mechanism, which is that reviews are grouped by feature slice and repairs are driven from a specific finding. The root of the tree also carries `.crabbox.yaml` and four scripts named for crabbox, hydrate, run, stop and warmup, while the manifest's dependency list contains nothing called crabbox, so those scripts assume a tool the package does not install. Alongside them sit `AGENTS.md`, `CHANGELOG.md`, `pnpm-workspace.yaml` for a repository with one package, two tsconfig files, and a docs directory holding the provider, quickstart, code review, feature mapping, configuration, findings, patching, reporting, validation and safety guides.

Editorial conclusion

Clawpatch suits a maintainer who wants review, patching and revalidation to be explicit steps with saved evidence rather than one long agent session, and who already has a coding agent installed and authenticated. Do not adopt it expecting it to review your code on its own: the default provider is the local Codex CLI, there is no direct model call, and the interesting claims come from the provider you point it at. Before the first review, decide which language mappers apply to your repository and whether the deterministic mapping is enough, because the agent assisted modes change what gets sliced. Know that open-pr is a separate command that commits and pushes, that clawpatch itself never merges, and that the state directory is committed-adjacent local data holding findings, patches and run history.

Frequently asked questions

Official sources

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