ClawSweeper
github.com/openclaw/clawsweeper- Category
- Developer Tools
- Rank
- No. 2568Tools index
Previous survey · No. 2427 ·
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Software Testing & Quality
- Builder
- @steipete
- GitHub
- 2.0k stars
- Latest release
- v0.2.0
- Date
About
An automated GitHub bot that intelligently reviews open issues and pull requests to suggest which ones can be closed based on predefined criteria. It helps maintainers manage repository health by identifying stale, implemented, or invalid issues without manual review.
What it does
ClawSweeper is the maintenance bot the OpenClaw project runs on its own GitHub backlog. On a schedule and on individual GitHub events, it has a Codex coding agent read each open issue or pull request, write a durable report, and keep one public comment per item updated in place. Separate guarded steps can then close items, label them, repair opted-in pull requests, or merge them once checks pass. A dashboard on Cloudflare Workers shows queue and lane activity through read-only aggregate endpoints.
Why it's ranked here
The case rests on how carefully it separates judgement from authority. The model proposes; deterministic code owns every GitHub write, and each close or merge is rechecked against live state right before it happens. Merges are pinned to the exact reviewed commit, so a branch that moves after review cannot slip through. Close reasons are an enumerated list, maintainer-authored items stay open unless already implemented, and capacity limits live in one validated config. It is MIT licensed. The cost is that it is built for OpenClaw first, and adopting it means forking and self-hosting.
What's good
The automerge design is concrete: a pass marker can merge only the commit it names, any repair push invalidates it and forces a re-review, and pending checks are treated as waits rather than failures, with two ten-minute wait windows absorbing GitHub lag. Repair caps exist per pull request and per head. The public dashboard endpoints return only allowlisted counts and fail closed on malformed data. A documentation checker validates links, script names and quoted config values against the repository, so docs drift gets caught in CI.
Tradeoffs
This is not a product you install. The hosted instance does not review third-party repositories; the README says to fork, deploy in your own organization and configure it yourself. The operating surface is large: well over sixty package scripts, Cloudflare Workers, Durable Objects, R2 storage and a separate state repository. It requires Node 24 or newer and pnpm. Much of the repository config and policy is shaped around OpenClaw's own repos, and the vision document openly prefers model judgement over deterministic machinery outside the trust boundary, which suits a team comfortable auditing model output.
How to use it well
Treat it as a reference architecture before treating it as a tool. A maintainer running a busy open source project with Codex access and a Cloudflare account can fork it, point it at their repositories, and start with review-only comments, leaving the close, automerge and issue-to-PR lanes off until the reports prove trustworthy. The local branch review command is the lightest entry point. It does not cover releases, and teams without an operator willing to own the config and runbooks will struggle.
Technical notes+
package.json declares a private ESM TypeScript package with only yaml and yauzl as runtime dependencies, an engines floor of Node 24 and pnpm as package manager; tests run through node --test with coverage floors. config/automation-limits.json holds one global knob, workers.max at 128, from which docs/limits.md derives lane caps as percentages (normal review 70 percent, repair 40 percent) and a queue-pressure throttle. docs/orchestration.md lists what must stay deterministic: authorization, repo boundaries, exact-head checks, worker budgets and final mutations. docs/repair/automerge-flow.md specifies the exact-head rule and shepherd and router waits. src/repair/lib.ts validates repair job frontmatter, rejects security-sensitive jobs, and compacts prompt artifacts above 320,000 characters.
Observed
- License
- MIT
- Language
- TypeScript (ESM), Node 24 or newer
- Package manager
- pnpm; package marked private, not published to npm
- Deployment
- Self-hosted fork; hosted instance serves OpenClaw repositories only
- Infrastructure
- GitHub Actions, Cloudflare Workers, Durable Objects and R2
- Model runtime
- Codex for review and repair
- Interfaces
- GitHub comment commands, CLI scripts, read-only dashboard HTTP API
- Runtime dependencies
- Two (yaml, yauzl)
Read from README.md, package.json, LICENSE, VISION.md, docs/README.md, docs/limits.md, docs/orchestration.md, docs/public-api.md, docs/repair/automerge-flow.md, docs/operator-configuration.md, src/repair/lib.ts, config/automation-limits.json.
What it can do
Automatically review open GitHub issues
Open GitHub issues in a repository → Markdown records documenting review findings
Automatically review open GitHub pull requests
Open GitHub pull requests in a repository → Markdown records documenting review findings
Identify stale issues for closure
GitHub issues with timestamps and activity history → List of stale issues recommended for closure
Detect already implemented features in issues
GitHub issues and repository codebase → List of issues describing already implemented features
Flag invalid issues for closure
GitHub issues content and predefined validity criteria → List of invalid issues recommended for closure
Automatically close issues based on evidence
Issues meeting strong evidence criteria for closure → Closed GitHub issues with closure reasoning
Tags
Tech Stack
Featured in Intel
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.