How ClawSweeper reviews OpenClaw issues

ClawSweeper starts with planning, not closing

The most important detail in the ClawSweeper workflow is that the normal path is proposal-only. A scheduled sweep does not immediately comment on or close OpenClaw issues. Instead, it starts with a planner job that scans GitHub, identifies which issues and pull requests are due for review, and hands exact item numbers to review workers. That design matters because each review shard receives a bounded list of planned items rather than broad authority over the repository.

The README describes a cadence system that keeps active work fresh without ignoring older backlog. Items with activity since the last stored snapshot, all pull requests, and issues younger than thirty days are reviewed daily. Older inactive issues move to a weekly review cadence. When more items are due than can fit in one run, the planner prioritizes active items first, then pull requests, then newer issues, and finally older weekly reviews. That prioritization is a practical answer to a large repository problem: the bot should spend attention where maintainer context is most likely to change.

The public dashboard is part of this workflow. It reports open issue counts, open pull request counts, reviewed files, proposed closes, archived closed files, stale or failed reviews, and cadence coverage. For a searcher trying to understand ClawSweeper, those numbers show that this is not a toy example. The project tracks thousands of OpenClaw items and uses the dashboard as a live operational summary of review progress.

How Codex review shards work

After planning, the workflow checks out the ClawSweeper repository, sets up Node 24, installs dependencies, and builds the TypeScript project. Each review shard also checks out openclaw/openclaw at main. The workflow uses cached git objects to make startup faster, but each review still runs against the current main branch state selected by the workflow.

Codex is invoked with the model and reasoning settings documented in the README. The workflow uses a ten-minute per-item timeout, while the review job as a whole has a broader timeout so a stuck shard cannot hold the review concurrency group forever. Each shard emits progress lines, writes review artifacts, and uploads them for the publish job. The result is a parallel review process that can handle many items while still preserving one review record per issue or pull request.

The review checkout is treated as evidence, not as a write target. Codex runs without GitHub write tokens during review, and the runner checks the OpenClaw checkout before and after every review. If Codex leaves tracked or untracked changes behind, the item fails rather than silently accepting a mutated local tree. That safeguard protects the meaning of the review record: the markdown file should describe what was found, not hide local edits made during inspection.

The markdown artifact is the center of the workflow

ClawSweeper writes review output into items/<number>.md. A record stores the issue or pull request number, type, title, URL, author, labels, creation and update times, review timestamp, main branch SHA, latest release at review time, review mode, review status, snapshot hash, decision, close reason, confidence, and action taken. Below the front matter, the record contains a human-readable summary, evidence, risks or open questions, and the proposed close comment when a close is recommended.

This is why the ClawSweeper workflow is different from a bot that only leaves comments. The markdown artifacts become a durable audit trail in the openclaw/clawsweeper repository. Maintainers can inspect records later, compare them to the linked GitHub item, and understand why an item was kept open or marked proposed_close. Search engines also benefit from this clear topic structure: ClawSweeper is about AI issue triage, but the content is anchored in concrete repository operations.

Publishing artifacts and continuing a sweep

Once review shards finish, the publish job downloads review artifacts, runs apply-artifacts, reconciles folders, and updates the README dashboard. If the planner filled the available worker capacity and the run is still in proposal-only mode, the publish job can queue another sweep. This continuation behavior lets ClawSweeper work through a large backlog without requiring one enormous workflow run.

The folder layout is part of the publishing process. Open items that still need tracking remain in items/. Successfully closed or already-closed records move to closed/. Folder reconciliation also compares tracked files with the current GitHub open set: externally closed items move from active tracking into the archive, while reopened archived items move back to items/ as stale records so the planner reviews them again. That reconciliation makes the repository a closer reflection of the real OpenClaw issue state.

Apply-existing is intentionally separate

The workflow can apply unchanged proposed decisions later through apply_existing=true. This mode does not rerun Codex. It reads existing markdown records, refetches the GitHub context, recomputes the snapshot hash, and only comments or closes if nothing changed since the proposal was written. If the item changed, is already closed, or is maintainer-authored, apply mode skips it.

Apply runs work in checkpoints. The README describes a default five-second close delay, fifty fresh closes per checkpoint commit, and long retry backoff for GitHub secondary write throttling. The apply workflow also caps total processed items separately from fresh closes, leaving enough scan room to skip changed or already-closed records while still reaching the requested number of fresh closures. If a run reaches the requested close limit, it can queue another apply run with the same settings.

Local operation and checks

The README documents a local run path for maintainers. It requires Node 24, installs dependencies, builds the project, runs plan, runs review against a local OpenClaw checkout, applies review artifacts, and can run reconciliation in dry-run mode. A separate command applies unchanged proposals later. The documented checks are npm run check and npm run oxformat, with the README noting that oxformat is an alias for oxfmt.

For GitHub Actions, the project expects an OpenAI API key for Codex and a GitHub token with write access to OpenClaw issues and pull requests. The workflow logs Codex in with the OpenAI key, passes the Codex API key to codex exec, and uses the OpenClaw GitHub token only for comments and closures. The built-in repository token commits review markdown back to openclaw/clawsweeper. That separation of responsibilities is a major reason the ClawSweeper workflow can be described as conservative.