ClawSweeper: A Conservative Maintenance Bot for OpenClaw Repositories
ClawSweeper scans all issues and PRs and suggest what we can close, and why. It runs every PR / Issue once a week.
At a glance
- What is it?
- ClawSweeper scans open issues and PRs weekly, writes durable markdown reports, and suggests closures with guarded apply logic. It is built for OpenClaw's own repos, not as a generic auto-close service.
- Who is it for?
- Adopt ClawSweeper if you maintain an OpenClaw or steipete public repository and want proposal-only reviews with guarded apply, not an aggressive auto-closer. Skip it if you need a general-purpose bot for third-party repos; the hosted instance is not a public service and self-hosting requires Cloudflare Workers, R2, and a state repository.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What ClawSweeper Actually Does
ClawSweeper is a maintenance bot tuned for OpenClaw repositories. It reviews open issues and pull requests on a weekly schedule and on exact GitHub events, then writes one durable markdown report per item. The reports live in generated state, not in comments. A single marker-backed public review comment is synced per issue or PR and edited in place. The bot suggests what can be closed and why, but it does not close anything on its own. Apply mode is guarded: it re-fetches live GitHub state and checks labels, maintainer authorship, paired issue/PR state, snapshot drift, and repository profile rules before commenting or closing. The README is explicit that this is not a generic auto-close bot. Review is proposal-only, apply is guarded, and Codex never gets write credentials during review. Every GitHub mutation is rechecked against live target state immediately before it happens. That conservative posture is the core design, not a side feature.
The Mechanism: Reports, Comments, and State
Each review writes a file at records/<repo-slug>/items/<number>.md. That file contains the decision, evidence, a proposed maintainer-facing comment, runtime metadata, and a GitHub snapshot hash. The bot then syncs one public review comment per item. If a review starts before a completed comment exists, it posts a short status placeholder and later replaces that same comment with the final review. Pull request comments include hidden verdict and action markers so trusted repair and automerge flows can continue without parsing visible prose. Canonical review records live in a Cloudflare Durable Object store and are snapshotted to R2. Immutable ledger events, published assets, and a bounded content-addressed retry cache also live in R2. The state branch of openclaw/clawsweeper-state retains only jobs, results, notifications, and apply reports. The main branch of that same repository is the dashboard renderer source. This split keeps operational state separate from renderer code. The script scripts/hydrate-state.ts combines those sources for local use.
Getting It Running: Self-Hosted Deployment
The README is clear that the OpenClaw-hosted instance is not a public review service. It does not provide free reviews for third-party repositories. If you want ClawSweeper for your own project, you must fork the repository, deploy it in your own organization, and configure that self-hosted instance for your repositories. The production targets are openclaw/openclaw, openclaw/clawhub, openclaw/clawsweeper, and openclaw/fs-safe. Additional public openclaw/* and steipete/* repositories can use configured profiles or a conservative generic fallback review through event dispatch and scheduled fanout. There is no one-line install command in the README. Deployment involves Cloudflare Workers for the dashboard, R2 for assets and ledger, and a separate state repository. The contributing guide explains when to use @clawsweeper re-review and why a changed head or PR body needs fresh evidence. That command is a real entry point for maintainers, but the exact setup steps live in the docs directory, not in the README.
Command Routing and Repair Loops
ClawSweeper routes maintainer commands such as @clawsweeper review, @clawsweeper fix, @clawsweeper autofix, and @clawsweeper automerge. It can acknowledge these commands through an optional GitHub App webhook before the GitHub Actions fallback starts. For opted-in PRs, it repairs them through a bounded Codex review/fix loop before merge. The loop is bounded, which means it does not run forever. For viable reviewed issues in eligible public openclaw/* and steipete/* projects, it automatically opens guarded implementation PRs. There is also a local branch range review mode where repository and GitHub access stay local while Codex connects to the configured model service. The README mentions GitCrawl intake, durable Codex threads, CrabFleet steering, completion gates, quotas, and dashboards, but the details are in docs/steerable-repair-automation.md. The key point is that Codex is involved in repair and automerge, but never with write credentials during review. That separation is a deliberate safety boundary.
Advisory Labels and Decision Packets
For open issues with complete, current kept-open reviews, ClawSweeper projects selected structured review conclusions into advisory GitHub labels. These labels expose states such as current-main reproduction, source reproduction, linked open PRs, queueable fixes, verified small bugs suitable for good first issue, missing info, and product or security review needs. The labels are advisory only and do not trigger repair, merge, or close behavior. Label-only syncs record labels_synced_at in the durable report so GitHub updated_at changes caused by ClawSweeper-owned label writes do not look like fresh target-side activity to the scheduler. That detail matters because the scheduler uses GitHub timestamps to decide what to re-review. Separately, apply and artifact replay maintain Codex-authored decision packet JSON at records/<repo-slug>/decision-packets/<number>.json for reports that need a maintainer ruling. Codex supplies the exact question, rationale, options, recommendation, and likely owner as structured output. Deterministic code validates that intent and removes stale packets. You can pass --decision-packets-dir to write those files elsewhere.
Limitations and Wrong-Tool Cases
ClawSweeper is not a generic auto-close bot, and it is not a public service. If you run a small project outside the openclaw or steipete namespaces, you cannot use the hosted instance. You would need to fork and deploy the entire stack, which involves Cloudflare Workers, R2, and a state repository. That is a heavy lift for a simple cleanup bot. The README also says new reviews do not generate live proof artifacts. Validation, rendering, media publication, and retraction are preserved for historical artifacts, but new reviews skip that. If you need live proof for every review, this bot is the wrong choice. Another limitation is the marker-backed comment model. Each item gets exactly one comment, edited in place. If your maintainers expect a threaded discussion or multiple comment updates, that model will feel restrictive. The bot also depends on GitHub Actions and event dispatch. If your repository cannot forward repository_dispatch events, you lose the low-latency one-item reviews and fall back to weekly scans only.
Alternatives and Maintenance Cost
A direct alternative is a simple GitHub Action that uses a cron schedule and a script to label stale issues, like actions/stale. That tool is far simpler, requires no Cloudflare infrastructure, and is public by default. The difference in approach is fundamental: actions/stale applies a fixed age threshold and closes issues without per-item reasoning. ClawSweeper reviews each item with a model, writes a durable report, and closes only unchanged, high-confidence, policy-allowed proposals. If you only need to sweep old issues, actions/stale is cheaper and easier. ClawSweeper is for repositories that want structured review evidence and guarded apply. On maintenance cost, the README does not give upgrade instructions. The project is under the MIT license, which permits reuse and modification. The separate state repository and R2 buckets add operational overhead. The docs directory is the place to find recovery and dashboard guidance, but the README itself is thin on upgrade paths. You should budget time for reading docs/steerable-repair-automation.md before adopting it.
Editorial conclusion
Adopt ClawSweeper if you maintain an OpenClaw or steipete public repository and want proposal-only reviews with guarded apply, not an aggressive auto-closer. Skip it if you need a general-purpose bot for third-party repos; the hosted instance is not a public service and self-hosting requires Cloudflare Workers, R2, and a state repository. Verify first that your repo can tolerate one marker-backed comment per item, that you accept Codex-based repair loops only for opted-in PRs, and that your GitHub Actions permissions match the documented event dispatch model.
Community notes