ClawSweeper: the conservative maintenance bot for OpenClaw repositories

The backlog problem ClawSweeper targets

Open source maintainers accumulate issues and pull requests faster than they can read them. ClawSweeper addresses that specific backlog: it scans all issues and PRs and suggests what can be closed, and why, running each item through review once a week. The README frames it as "the conservative maintenance bot for OpenClaw repositories," and the conservatism is the point. It is not a generic auto-close bot. Review is proposal-only, apply is guarded, and Codex never receives write credentials during review.

The intended audience is narrow. The dashboard Worker's explicit production targets are openclaw/openclaw, openclaw/clawhub, openclaw/clawsweeper and openclaw/fs-safe. Other public openclaw/* and steipete/* repositories can be covered through configured profiles or a conservative generic fallback review, dispatched by events or a scheduled fanout. If your project lives outside those namespaces, the README tells you to fork the repository, deploy it in your own organization, and configure that self-hosted instance for your repositories. The hosted instance does not provide free reviews for third-party repositories, so this is not a service you point at your project and forget.

How a review becomes a report, a comment and a proposal

The mechanism is a pipeline with durable state at every step. Scheduled runs scan open issues and pull requests; target repositories can also forward exact issue and PR events through repository_dispatch for low-latency one-item reviews. Each review writes records/<repo-slug>/items/<number>.md containing the decision, the evidence, the proposed maintainer-facing comment, runtime metadata and a GitHub snapshot hash.

On the public side, ClawSweeper syncs one marker-backed review comment per item and edits it in place rather than posting repeatedly. If a review starts before a completed comment exists, it posts a short status placeholder first, then replaces that same comment with the final review. Pull request comments carry hidden verdict and action markers so trusted repair and automerge flows can continue without scraping visible prose.

Review prompts pull in compact related context: explicit links, linked closing PRs, existing local ClawSweeper reports, optional gitcrawl clusters, and opt-in live GitHub issue search for exact event reviews. The README is careful to call this advisory context for duplicate and superseded reasoning, not a standalone close decision. Reviews also persist a typed, proposal-only root-cause assessment with same-repository URLs and at most one evidence-backed canonical item, and that assessment does not dispatch repair, suppress jobs, mutate siblings, close or merge.

Apply mode is where anything actually changes. It re-fetches live GitHub state and checks labels, maintainer authorship, paired issue and PR state, snapshot drift and repository profile rules before commenting or closing. Closed reports move to records/<repo-slug>/closed/<number>.md; reopened archived items move back to items/ as stale work. Canonical review records live in a Cloudflare Durable Object store and are snapshotted to R2, alongside immutable ledger/v1/ action events, published assets/ and a bounded content-addressed artifacts/exact-review/v1/ retry cache.

Installing ClawSweeper from a fork and running a first review

The repository is a private pnpm workspace package named @openclaw/clawsweeper, licensed MIT, written in TypeScript. The README does not present a published npm install for third parties; it directs you to fork the repository and deploy it in your own organization. The package.json scripts show the build and run path. Install dependencies with pnpm, then build the Node targets:

pnpm install
pnpm run build:node

build:node runs tsc against tsconfig.json and tsconfig.repair.json, producing dist/clawsweeper.js and the repair entry points. The plan command is the read-only starting point; it reports what the configured profiles would do without mutating GitHub:

node dist/clawsweeper.js plan

A single review run goes through the review script, which the package.json maps to the same compiled entry point:

pnpm run review

Before any of this touches a real repository, check the local Codex wiring, because review connects to a configured model service:

pnpm run codex:local:check

What you should see is a plan output describing target repositories and pending work, then review output that writes records/<repo-slug>/items/<number>.md files into generated state. The README also lists retry-failed-reviews, apply-artifacts, apply-decisions, audit, reconcile and status as operational commands for the same binary. Treat apply mode as a separate decision: it is the step that comments or closes, and it rechecks live state immediately before each mutation.

Where ClawSweeper is the wrong tool

The strongest limitation is stated by the project itself: the OpenClaw-hosted instance is not a public review service and does not provide free reviews for third-party repositories. Anyone hoping to add a bot to their own project by inviting an app is reading the wrong document. Self-hosting is the only supported path, and that means running a Worker, an R2 bucket, a Durable Object store and a state repository, plus a Codex connection for the review loop.

The second constraint is scope. The explicit production targets are four OpenClaw repositories. Everything else runs through configured profiles or a conservative generic fallback, which by definition will be less informed than a profile tuned for a known codebase. If your project has unusual contribution rules, a fallback review will not know them.

The third is the review cadence. Scheduled runs scan each item once a week. If you need a verdict within minutes of an issue opening, you have to wire up repository_dispatch event forwarding, and the README notes that live GitHub issue search for related context is opt-in and limited to exact event reviews. There is also a hard boundary around automation: Codex never gets write credentials during review, so a review cannot fix anything by itself. Repair happens through the separate bounded Codex review and fix loop on opted-in PRs, and automerge is a routed maintainer command rather than an automatic outcome. If you want a bot that closes stale issues unattended, this is not it; closing is limited to unchanged, high-confidence, policy-allowed proposals.

ClawSweeper compared with a label-and-stale workflow

The obvious alternative is the familiar combination of GitHub Actions plus a stale-issue action, where a timer labels inactive items and closes them after a fixed period. The difference in approach is that a stale bot reasons from timestamps alone, while ClawSweeper reasons from content: it writes a per-item markdown report with a decision and evidence, persists a typed root-cause assessment, and projects selected structured conclusions into advisory labels 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.

That label projection is advisory only. The README states it does not trigger repair, merge or close behavior, and label-only syncs record labels_synced_at in the durable report so that ClawSweeper-owned label writes do not look like fresh target-side activity to the scheduler. A stale bot has no equivalent concern because it does not care why an item changed.

The cost of the richer approach is operational surface. A stale action is a few lines of YAML. ClawSweeper needs generated state, decision packets at records/<repo-slug>/decision-packets/<number>.json for reports that need a maintainer ruling, a state branch that retains only jobs/, results/, notifications/, apply-report.json and repair-apply-report.json, and a hydration script, scripts/hydrate-state.ts, to combine those sources locally. You are trading simplicity for evidence, and the trade only pays off if maintainers actually read the reports.

Maintenance status, licence and upgrade cost

The repository is not archived. Its last push was on 2026-05-03, and the most recent release listed is v0.3.0 from 2026-06-15, following v0.2.0 and v0.1.0 on 2026-05-03. The package.json version is 0.3.1, so the working tree is slightly ahead of the last tagged release. With no push since 2026-05-03, treat this as a project whose activity should be checked directly on the repository before you build a workflow around it.

The licence is MIT, which is permissive and places few conditions on forking and redeploying. That matters here because self-hosting is the documented path. Note only that the repository does not describe how the hosted dashboard at clawsweeper.bot is governed, and MIT covers the code in this repository rather than any hosted service; if you need clarity on service terms, that is a question for the project, not something the licence text answers.

The upgrade cost is dominated by state layout rather than code. The state branch of openclaw/clawsweeper-state retains jobs/, results/, notifications/, apply-report.json and repair-apply-report.json, while its main branch remains the dashboard renderer source. Any upgrade that changes those paths or the records/ layout affects hydration and reporting. Command-line surface is also wide: plan, review, reserve-review-lease, retry-failed-reviews, apply-artifacts, apply-decisions, finalize-action-events, publish-action-events, audit, reconcile and status all exist as scripts, plus a separate local-review entry point and a set of repair:* validation scripts. Pinning a release and reading CHANGELOG.md before moving is cheaper than discovering a renamed state directory during an incident.

Editorial conclusion

Adopt ClawSweeper only if you are prepared to fork it, deploy it inside your own organization and configure it for your own repositories, because the OpenClaw-hosted instance is explicitly not a public review service. Teams that want a generic auto-close bot, or that cannot run a Codex-connected review loop, should look elsewhere. Before committing, read docs/steerable-repair-automation.md for the operator model and check that your repository profile rules and the apply-mode guards match how your maintainers actually work.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes