[Bug]: ClawSweeper queueable labels do not protect actionable OpenClaw issues from stale automation

[brokemac79]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When ClawSweeper marks an OpenClaw issue as source-reproduced and queueable, it does not currently add a stale-exempt marker such as no-stale or otherwise intentionally remove/protect against stale.

Steps to reproduce

1. Let Barnacle mark an eligible OpenClaw issue as stale.
2. Let ClawSweeper review the issue and add actionable labels such as clawsweeper:queueable-fix, clawsweeper:source-repro, and clawsweeper:fix-shape-clear.
3. Observe that the issue can still have stale, or that Barnacle later removes stale only because ClawSweeper label writes changed the issue updated_at.

Observed examples on June 2, 2026:

• fix(memory): EPERM on Windows persists after 64187 retry — needs copyFile/unlink fallback (was in closed PR 71611) openclaw#78640 has stale and clawsweeper:queueable-fix.
• [Bug]: WhatsApp block streaming can suppress complete final replies after partial stream delivery openclaw#81078 has stale and clawsweeper:queueable-fix.
• Bug: Twilio voice-call can get stuck in hold music after failed/no-stream call openclaw#81122 has stale and clawsweeper:queueable-fix.
• Upgrade leaves stale user-level systemd unit, dueling services kill each other on Linux openclaw#79375 showed the stale label being added by Barnacle, ClawSweeper adding queueable labels, and Barnacle later removing stale after the issue was updated.

Expected behavior

When ClawSweeper classifies an issue as an actionable queued fix candidate, it should intentionally protect that issue from stale closure.

Reasonable behavior would be one or more of:

• Add no-stale when adding clawsweeper:queueable-fix.
• Remove stale when adding clawsweeper:queueable-fix.
• Add a durable ClawSweeper-specific stale-exempt label that the OpenClaw stale workflow exempts.
• Add an audit/report for queueable issues that still have stale or lack stale protection.

Actual behavior

ClawSweeper can add actionable labels while leaving the issue stale-eligible or still carrying stale.

The current behavior relies on OpenClaw's stale workflow noticing that the issue updated_at changed and removing stale on a later run. That is indirect and can create confusing label churn between Barnacle and ClawSweeper.

OpenClaw version

OpenClaw issue state observed on June 2, 2026.

Operating system

N/A - GitHub App / repository automation behavior.

Install method

ClawSweeper GitHub App / scheduled or event-driven issue review.

Model

N/A for the stale-protection behavior. ClawSweeper review comments observed on related issues mention Codex review model gpt-5.5, but the stale protection bug is label automation behavior.

Provider / routing chain

ClawSweeper GitHub App -> OpenClaw issue review -> GitHub issue labels.

Additional provider/model setup details

ClawSweeper is itself a bot. Its issue label updates should be treated as bot automation and should not be the only reason an issue exits the stale lifecycle.

Logs, screenshots, and evidence

Representative current labels:

stale
clawsweeper:queueable-fix
clawsweeper:source-repro
clawsweeper:fix-shape-clear

Current live examples:

• fix(memory): EPERM on Windows persists after 64187 retry — needs copyFile/unlink fallback (was in closed PR 71611) openclaw#78640
• [Bug]: WhatsApp block streaming can suppress complete final replies after partial stream delivery openclaw#81078
• Bug: Twilio voice-call can get stuck in hold music after failed/no-stream call openclaw#81122

Prior churn example:

• Upgrade leaves stale user-level systemd unit, dueling services kill each other on Linux openclaw#79375

The broader queueable data/message-loss search showed 13 issues where stale was removed after ClawSweeper label/update activity, plus 3 issues currently carrying both stale and clawsweeper:queueable-fix.

Impact and severity

Affected: OpenClaw maintainers using ClawSweeper to identify work candidates.

Severity: Medium to high for automation reliability. Queueable issues can appear inactive or move toward stale closure despite being actively classified by ClawSweeper.

Frequency: Observed across multiple queueable issues.

Consequence: Maintainers may lose trust in stale labels, ClawSweeper queue labels, or both. Actionable issues may require manual rescue before stale closure.

Additional information

Companion OpenClaw issue: openclaw/openclaw#89564.

I plan to work on a PR for this issue and a linked PR for the companion OpenClaw stale workflow issue. The ClawSweeper PR should stay focused on making queueable/actionable labels intentionally stale-safe.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 2, 2026, 1:52 PM ET / 17:52 UTC.

Summary
Keep open: current main still syncs queueable/actionable ClawSweeper issue labels without adding a stale exemption or removing stale, and live OpenClaw examples currently show both stale and clawsweeper:queueable-fix.

Reproducibility: yes. source and live-state evidence give a high-confidence reproduction path: current main can select clawsweeper:queueable-fix without stale protection, and live OpenClaw issues currently carry both stale and clawsweeper:queueable-fix.

Next step
This is a narrow, source-reproducible ClawSweeper label-sync bug with clear files and validation, and no open linked implementation PR is present.

Review details

Best possible solution:

Make the ClawSweeper advisory-label sync add a durable stale exemption such as no-stale and remove stale when an OpenClaw issue becomes queueable/actionable, with tests and docs covering the label transition.

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

Yes, source and live-state evidence give a high-confidence reproduction path: current main can select clawsweeper:queueable-fix without stale protection, and live OpenClaw issues currently carry both stale and clawsweeper:queueable-fix.

Is this the best way to solve the issue?

Yes, the narrowest maintainable fix is to extend the existing advisory-label sync path so actionable queue labels intentionally set or clear stale-protection state, rather than relying on GitHub updated_at side effects.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The ClawSweeper-side repair should stay aligned with [Bug]: Stale workflow does not exempt ClawSweeper queueable issues openclaw#89564; adding a marker that the OpenClaw stale workflow does not exempt would not fully protect actionable OpenClaw issues.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9c50a95427c2.

Label changes

Label changes:

• add P2: This is a real automation reliability bug with multiple live examples, but it is bounded to issue-label/stale triage behavior rather than an immediate runtime outage.
• add impact:other: The issue affects maintainer-visible stale and queueable-label reliability, which is outside the more specific ClawSweeper impact taxonomy.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a real automation reliability bug with multiple live examples, but it is bounded to issue-label/stale triage behavior rather than an immediate runtime outage.
• impact:other: The issue affects maintainer-visible stale and queueable-label reliability, which is outside the more specific ClawSweeper impact taxonomy.

Evidence reviewed

Acceptance criteria:

• pnpm run check
• node --test --test-name-pattern "issue advisory labels" test/clawsweeper.test.ts

What I checked:

• AGENTS.md policy read: Read the full target AGENTS.md; its conservative automation guidance supports keeping this open as a narrow automation bug rather than closing from incomplete evidence. (AGENTS.md:1, 9c50a95427c2)
• Advisory label definitions omit stale protection: The issue advisory label set defines clawsweeper:source-repro, clawsweeper:queueable-fix, and clawsweeper:fix-shape-clear, but no no-stale or other stale-exempt marker. (src/clawsweeper.ts:1254, 9c50a95427c2)
• Queueable label selection has no stale action: wantedIssueAdvisoryLabels adds clawsweeper:queueable-fix for high-confidence queue_fix_pr candidates and clawsweeper:fix-shape-clear for clear repair shape, with no stale removal or stale-exempt label in the same path. (src/clawsweeper.ts:9231, 9c50a95427c2)
• Sync code preserves unrelated labels: syncIssueAdvisoryLabels only adds or removes labels recognized by isIssueAdvisoryLabel, so an existing unrelated stale label is left in place by this sync path. (src/clawsweeper.ts:9429, 9c50a95427c2)
• Work-lane docs describe advisory labels only: The docs say advisory labels expose routing state and do not dispatch repair, merge, or close work; the documented label table includes queueable/source labels but no stale-safety behavior. (docs/work-lane.md:28, 9c50a95427c2)
• Live examples still show stale plus queueable: The GitHub API for fix(memory): EPERM on Windows persists after 64187 retry — needs copyFile/unlink fallback (was in closed PR 71611) openclaw#78640, [Bug]: WhatsApp block streaming can suppress complete final replies after partial stream delivery openclaw#81078, and Bug: Twilio voice-call can get stuck in hold music after failed/no-stream call openclaw#81122 returned labels including both stale and clawsweeper:queueable-fix.

Likely related people:

• Tak Hoffman: Blame ties the current issue advisory label definitions, selection logic, and work-lane docs to commit 3b76d34. (role: recent area contributor; confidence: high; commits: 3b76d34e75b9, 666e707a8288, 9f434e810ec9; files: src/clawsweeper.ts, test/clawsweeper.test.ts, docs/work-lane.md)
• Peter Steinberger: Recent history shows adjacent workflow and automation maintenance, including stale queued workflow capacity handling, which is relevant to label/stale automation routing. (role: adjacent automation contributor; confidence: medium; commits: f37d8cdc6cf0, 558017d383b7, d37dcfb8395b; files: .github/workflows/sweep.yml, src/clawsweeper.ts)
• brokemac79: Beyond reporting this issue, recent merged commits touch ClawSweeper review/apply command and close-safety behavior adjacent to this automation surface. (role: recent adjacent contributor; confidence: medium; commits: a07fc1f94275, 485f71abc664, f2ec021eb55c; files: src/clawsweeper.ts, test/clawsweeper.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.

[brokemac79]

Coordination note: Shadow (OpenClaw admin) mentioned in Discord that this stale/queueable behavior may be intentional.

Keeping this open for now while maintainers confirm the intended policy. If it is confirmed intentional that ClawSweeper queueable/actionable issues can still be marked stale, maintainers can close this as not planned. If not, this remains the proposed fix path.

[brokemac79]

Coordination note: Shadow (OpenClaw admin) mentioned in Discord that this stale/queueable behavior may have been intentional.

I’m leaving this issue open for now so maintainers can confirm the intended policy. If the intended policy is that ClawSweeper queueable/actionable issues may still be marked stale and remain eligible for stale handling, maintainers can close this as intentional / not planned.

If the intended policy is that queueable/actionable ClawSweeper issues should be protected from stale closure, this issue remains the proposed repair item.