ClawSweeper command status comment edits can re-enter activity handling and churn review labels

[ooiuuii]

ClawSweeper command status comment edits can re-enter activity handling and churn review labels

Summary

ClawSweeper command/status comments can be edited by clawsweeper[bot] while they still contain command markers and command-like text such as @clawsweeper re-review. Those bot-authored status comment edits appear to re-enter the GitHub activity lane as command-like activity, contributing to repeated ClawSweeper Dispatch runs, cancellations, and visible label/rating churn on a PR that had no new push and no new manual command.

This looks like the same class of self-comment inertness bug fixed for proof-nudge comments in #243, but for clawsweeper-command-status / clawsweeper-command-ack / progress marker comments.

Real incident

Observed on openclaw/openclaw#90328 (Expose model picker agent runtimes) on 2026-06-07.

After the final manual @clawsweeper re-review request, the PR still showed repeated ClawSweeper activity without new author pushes or new manual re-review comments.

Representative ClawSweeper Dispatch runs for #90328, all from issue_comment events:

27098166267  2026-06-07T16:25:24Z  completed success
27098147987  2026-06-07T16:24:41Z  completed success
27098142690  2026-06-07T16:24:26Z  completed cancelled
27098047591  2026-06-07T16:20:34Z  completed cancelled
27098028747  2026-06-07T16:19:51Z  completed cancelled
27098027944  2026-06-07T16:19:49Z  completed cancelled
27098027269  2026-06-07T16:19:47Z  completed cancelled
27098026607  2026-06-07T16:19:45Z  completed cancelled
27098023797  2026-06-07T16:19:38Z  completed success

The same window had visible label churn by clawsweeper[bot]:

2026-06-07T16:02:13Z  unlabeled  proof: sufficient
2026-06-07T16:02:15Z  unlabeled  proof: 📸 screenshot
2026-06-07T16:02:16Z  unlabeled  rating: 🦞 diamond lobster
2026-06-07T16:02:18Z  labeled    rating: 🌊 off-meta tidepool
2026-06-07T16:02:19Z  unlabeled  status: 👀 ready for maintainer look
2026-06-07T16:11:11Z  labeled    proof: sufficient
2026-06-07T16:11:12Z  labeled    proof: 📸 screenshot
2026-06-07T16:11:14Z  unlabeled  rating: 🌊 off-meta tidepool
2026-06-07T16:11:16Z  labeled    rating: 🐚 platinum hermit
2026-06-07T16:11:18Z  labeled    status: 👀 ready for maintainer look

The relevant command/status comment had hidden command markers and command-like visible text, e.g.:

<!-- clawsweeper-command-ack:4643099431 -->
<!-- clawsweeper-command-status:90328:re_review:bc62b391bf7f7c9e6ea722c5fd746ded2a5da612 -->
<!-- clawsweeper-command:4624832014:2026-06-04T18:01:54Z:re_review:bc62b391bf7f7c9e6ea722c5fd746ded2a5da612 -->

Expected behavior

ClawSweeper-authored command ack/status/progress comments should be inert when they are edited by the bot itself. They should not be treated as surprising GitHub activity or command-like input just because they contain marker text or repeat the original command.

A human-authored explicit command such as @clawsweeper re-review should still route normally.

Actual behavior

Bot-authored status comment edits with command/status markers appear to pass the command-like activity filter and can contribute to repeated activity dispatches and label churn. This makes a PR look like it is still being repeatedly reviewed even when no new author action occurred.

Related prior work

• Keep proof-nudge comments inert #243 fixed the same self-comment inertness class for proof-nudge comments that contain otherwise-routable @clawsweeper re-review text.
• re-review workflow reports "Complete" but durable verdict marker not refreshed to new head SHA #170 tracks a related symptom where re-review status says complete but durable verdict/head markers and labels can remain stale.
• Recent ClawSweeper commits also show this area is already being hardened: duplicate command ack convergence, fast ack parsing, and workflow storm reduction.

Suggested fix

Filter ClawSweeper-authored issue_comment activity when the comment body contains command ack/status/progress markers such as:

• clawsweeper-command-status:
• clawsweeper-command-ack:
• clawsweeper-command-progress:start

This should happen before treating the activity as command-like, while preserving normal human-authored command routing.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 7, 2026, 12:54 PM ET / 16:54 UTC.

Summary
Keep open: current main still lacks the command-status marker guard, and the linked open fix PR #267 is the right implementation path for this issue.

Reproducibility: yes. from source inspection: an issue_comment.edited event from clawsweeper[bot] whose body contains command markers plus visible @clawsweeper text makes commandLike true and bypasses the current routine edit/bot filters. I did not run tests because this review is read-only.

Next step
No separate repair lane should be queued because the issue is already paired with the open implementation PR #267.

Review details

Best possible solution:

Review and land, revise, or explicitly close #267; after a fix merges, this issue can close as implemented.

Do we have a high-confidence way to reproduce the issue?

Yes, from source inspection: an issue_comment.edited event from clawsweeper[bot] whose body contains command markers plus visible @clawsweeper text makes commandLike true and bypasses the current routine edit/bot filters. I did not run tests because this review is read-only.

Is this the best way to solve the issue?

Yes, the linked PR's approach is the narrowest maintainable fix: filter bot-authored command marker comments before command-like matching while keeping explicit human commands visible.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until Filter ClawSweeper command status activity #267 lands or is replaced, bot-authored command status edits can still be treated as fresh command-like activity on current main.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 413ef258a1ef.

Label changes

Label changes:

• add P1: The issue reports repeated ClawSweeper dispatches, cancellations, and visible label/rating churn on a live pull request without new human activity.
• add impact:other: The concrete impact is automation control-loop churn in ClawSweeper's GitHub activity handling, which is meaningful but outside the specific owned impact classes.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.

Label justifications:

• P1: The issue reports repeated ClawSweeper dispatches, cancellations, and visible label/rating churn on a live pull request without new human activity.
• impact:other: The concrete impact is automation control-loop churn in ClawSweeper's GitHub activity handling, which is meaningful but outside the specific owned impact classes.

Evidence reviewed

What I checked:

• Current activity filter lets command-like bot status edits through: On current main, routineGithubActivityReason computes commandLike before the issue-comment edit and bot-comment routine filters, so a bot-authored edited comment containing @clawsweeper text is not filtered by those branches. (src/repair/notify-github-activity.ts:379, 413ef258a1ef)
• Command detection reads the compacted comment body: activityContainsClawSweeperCommand includes the comment body excerpt in the text scanned by CLAWSWEEPER_COMMAND_RE, which matches the reported marker-backed status copy when it repeats command-like text. (src/repair/notify-github-activity.ts:431, 413ef258a1ef)
• Command status comments are a real current code path: The router updates existing command status comments and preserves ack markers, matching the issue's status-comment edit surface rather than a hypothetical path. (src/repair/comment-router.ts:2990, 413ef258a1ef)
• Linked implementation PR directly targets this issue: The open linked PR adds a pre-commandLike bot-marker guard for clawsweeper-command-status, clawsweeper-command-ack, and clawsweeper-command-progress markers, plus a regression test using the reported status marker shape. (src/repair/notify-github-activity.ts:379, 4e28966f1287)
• Git history provenance for the current filter: git blame shows the current routineGithubActivityReason implementation was introduced with the activity notifier in 1ff140f, which is still the active main-line behavior being reported here. (src/repair/notify-github-activity.ts:379, 1ff140ff45c6)
• Related self-comment inertness precedent: Commit 54422d9 fixed the same general inertness class for proof nudge comments, but that change touched src/clawsweeper.ts and tests rather than the GitHub activity notifier path involved in this issue. (src/clawsweeper.ts, 54422d977482)

Likely related people:

• Takhoffman: git blame attributes the activity notifier filter to commit 1ff140f, and commit 54422d9 handled the related proof-nudge self-comment inertness class. (role: introduced behavior and adjacent owner; confidence: high; commits: 1ff140ff45c6, 54422d977482; files: src/repair/notify-github-activity.ts, test/repair/notify-github-activity.test.ts, src/clawsweeper.ts)
• brokemac79: Commit 556268d recently changed duplicate command ack convergence across the command router and webhook surfaces that create and update the relevant marker comments. (role: recent command ack/status contributor; confidence: medium; commits: 556268dff3d9; files: src/repair/comment-router.ts, src/repair/comment-webhook.ts, test/repair/comment-router-core.test.ts)
• ooiuuii: The linked open PR Filter ClawSweeper command status activity #267 is authored by this user and directly implements the marker filter and regression test for this issue. (role: open fix author; confidence: medium; commits: 4e28966f1287; files: src/repair/notify-github-activity.ts, test/repair/notify-github-activity.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.