Why ClawSweeper stays conservative

The safety model begins with a narrow purpose

ClawSweeper is not designed to be a general GitHub automation agent. Its scope is deliberately narrow: it reviews open issues and pull requests in openclaw/openclaw, records what it found, and only recommends closure when the evidence fits a small set of allowed reasons. That narrow purpose is the first safety feature. A bot that can do anything is hard to reason about; a bot that can only triage a defined backlog under a documented policy is easier to audit.

The README states the operating rule clearly: everything outside the allowed close reasons stays open. That is a conservative default. The safety model assumes that many issues require human judgment, product context, or additional user reports. ClawSweeper only tries to remove work when the repository evidence is strong enough to make closure low-risk.

Proposal-only review prevents immediate side effects

The normal workflow is proposal-only. During review, Codex writes markdown records and can mark high-confidence allowed decisions as proposed_close, but the standard sweep does not comment on or close GitHub items. That separation gives maintainers a chance to inspect the record set before any public action is taken.

Manual review runs can be configured to apply closures, but the README presents the safer path as proposal first and apply_existing=true later. This matters for a large project because the cost of a bad close is not only one issue. A bad close can confuse users, hide a regression, or remove a valid contribution from maintainer attention. Proposal-only review keeps the high-volume part of the system focused on evidence rather than action.

Allowed close reasons are policy boundaries

ClawSweeper has five allowed close reasons. An issue can be closed if it is already implemented on main, cannot be reproduced on current main, belongs on ClawHub as a skill or plugin rather than in OpenClaw core, is too incoherent to be actionable, or is older than sixty days with insufficient data to verify the bug. These categories are not broad labels. They are policy boundaries that keep the bot away from product judgment and subjective prioritization.

Just as important, none is a valid close reason in the decision schema. A record can conclude keep_open with high confidence. This avoids a common automation failure mode where the bot feels pressure to take action. ClawSweeper can decide that the evidence is real, the feature is not implemented, the report is still useful, or the risks are too high. In those cases the correct action is to keep the item open.

Snapshot hashes protect against stale decisions

Every review record includes an item snapshot hash. This hash is a compact representation of the GitHub item context used during review. Apply mode refetches the current issue or pull request context, recomputes the hash, and compares it to the stored value. If the item has changed since the proposal was written, apply mode skips it.

This is one of the strongest parts of the ClawSweeper safety model. GitHub issues are live conversations. A user can add reproduction steps, a maintainer can clarify scope, a pull request can change, or a linked fix can appear after the review record was generated. Without a snapshot check, an apply run could act on stale evidence. With the snapshot check, unchanged proposals are eligible for action and changed items return to the review path.

Maintainer-authored items are excluded

Candidate planning and apply mode both read GitHub's author_association field. Items authored by OWNER, MEMBER, or COLLABORATOR are excluded from automated close actions. This rule recognizes that maintainer-authored issues and pull requests often carry project context that an external triage policy should not override automatically.

The exclusion also lowers social risk. A maintainer may open an issue as a tracking note, roadmap placeholder, or internal reminder. Even if the item looks stale or incomplete from a narrow evidence perspective, closing it automatically could damage the maintainer workflow. ClawSweeper treats those items differently, which is an important signal that the project values human ownership over raw cleanup speed.

Read-only review reduces operational risk

During review, Codex runs without GitHub write tokens. The workflow checks the OpenClaw checkout before each review, makes the checkout read-only in CI, checks it again after review, and fails the item if Codex leaves tracked or untracked changes behind. That protects the review environment from accidental mutation.

The GitHub Actions setup also separates responsibilities. OpenAI and Codex credentials authenticate the review process, while the OpenClaw GitHub token is used for comments and closures only in the appropriate apply path. The built-in repository token commits review markdown back to the ClawSweeper repository. This split keeps review, publication, and GitHub side effects from collapsing into one unbounded permission set.

Apply mode is guarded by checkpoints and throttling behavior

Apply mode defaults to issue cleanup, a minimum age of zero days, a five-second close delay, and fifty fresh closes per checkpoint commit. PR closure is not the default path. Apply runs also cap total processed items separately from fresh closes, which leaves room to skip already-closed, changed, or ineligible records while still finding valid fresh closes.

The README describes explicit behavior for GitHub secondary write throttling. When throttling triggers a long retry sleep, apply mode posts a best-effort heartbeat to the dashboard with checkpoint, processed count, and next retry delay. That visibility matters because long-running cleanup should not look frozen. A maintainer can see that the workflow is slowed by platform limits rather than silently failing.

Failure handling avoids fake certainty

The GitHub Actions setup fails a review shard instead of writing fallback review markdown if Codex authentication or output fails. That is a subtle but important safety decision. A missing or malformed AI result should not become a plausible-looking markdown record. By failing the shard, ClawSweeper keeps uncertain output out of the reviewed file set.

The dashboard also reports failed or stale reviews. Search visitors may see those numbers as simple status metrics, but they are part of the trust model. A cleanup bot should show where it is incomplete. When ClawSweeper surfaces stale or failed records, it gives maintainers a clear path to rerun reviews rather than treating the backlog as fully resolved.

Why the conservative design is good SEO content

A useful ClawSweeper explainer should not only repeat that the project is an AI issue cleanup bot. The safety model is the reason the project is interesting. It combines AI review, GitHub workflow automation, markdown audit records, snapshot validation, maintainer exclusions, and checkpointed apply runs into a system that can operate on thousands of items without pretending that every stale issue is safe to close.

That is also why this page is a standalone topic page on clawsweeper.click. People searching for ClawSweeper may want to know whether it is safe, whether it closes issues automatically, how it handles changed items, and why maintainers would trust it. The answer is not a single feature. It is the combination of conservative policy, durable records, permission separation, and final snapshot checks.