PR status label misroutes security-owner review as waiting on author

[brokemac79]

Summary

ClawSweeper can leave a PR labeled status: ⏳ waiting on author even when the durable review says the PR is ready for maintainer review and the only remaining action is sandbox/security owner acceptance.

Live example: openclaw/openclaw#90798

Latest durable review state on that PR:

• Result: ready for maintainer review
• proof: sufficient
• remaining action: human sandbox/security owner acceptance for the new read-only sandbox skill exposure
• no concrete author-facing code/proof/doc action remains

Actual label state after re-review still includes:

• status: ⏳ waiting on author

That label description says ClawSweeper is waiting for author action, which is misleading for security-boundary PRs where the next step is owner/security review.

Source-level cause

In src/clawsweeper.ts, hasUnresolvedContributorWork() treats securityReview.status === "needs_attention" as unresolved contributor work:

• clawsweeper/src/clawsweeper.ts

  Lines 8896 to 8907 in 413ef25

  	function hasUnresolvedContributorWork(options: {
  	realBehaviorProof: Pick<RealBehaviorProof, "status">;
  	reviewFindings: readonly Pick<ReviewFinding, "priority">[];
  	securityReview: Pick<SecurityReview, "status">;
  	overallCorrectness: OverallCorrectness;
  	}): boolean {
  	return (
  	proofNeedsContributorAction(options.realBehaviorProof) ||
  	hasBlockingReviewFindings(options.reviewFindings) ||
  	options.securityReview.status === "needs_attention" ||
  	options.overallCorrectness === "patch is incorrect"
  	);

Then prStatusLabelKind() maps any remaining unresolvedWork to waiting_on_author before it can reach ready_for_maintainer_look:

• clawsweeper/src/clawsweeper.ts

  Lines 8926 to 8941 in 413ef25

  	function prStatusLabelKind(options: {
  	realBehaviorProof: Pick<RealBehaviorProof, "status">;
  	reviewFindings: readonly Pick<ReviewFinding, "priority">[];
  	securityReview: Pick<SecurityReview, "status">;
  	overallCorrectness: OverallCorrectness;
  	hasAutomergeLabel: boolean;
  	hasRecentReReviewRequest: boolean;
  	hasRecentAuthorActivity: boolean;
  	}): PrStatusLabelKind | null {
  	const unresolvedWork = hasUnresolvedContributorWork(options);
  	if (options.hasAutomergeLabel) return "automerge_armed";
  	if (options.hasRecentReReviewRequest) return "re_review_loop";
  	if (options.hasRecentAuthorActivity && unresolvedWork) return "actively_grinding";
  	if (proofNeedsContributorAction(options.realBehaviorProof)) return "needs_proof";
  	if (unresolvedWork) return "waiting_on_author";
  	if (isReadyForMaintainerLook(options)) return "ready_for_maintainer_look";

This makes sense for proof gaps, P0-P2 review findings, and incorrect patches, but not for cases where securityReview.needs_attention only means "human sandbox/security owner must accept the boundary before merge."

Expected behavior

When the only remaining blocker is human security/sandbox owner acceptance, ClawSweeper should not label the PR as waiting on the author.

Possible fixes:

• Add a distinct status label for human/security owner review, for example status: needs security review or status: needs maintainer/security review.
• Or allow ready_for_maintainer_look when proof is sufficient, patch is correct, there are no P0-P2 review findings, and securityReview.needs_attention is owner-acceptance rather than a concrete author-remediable security defect.

Why it matters

Maintainers scanning queues may read waiting on author as "do not review yet," even when ClawSweeper's review text says the PR is ready and needs security/owner review. That can stall security-boundary PRs in the wrong queue.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 10, 2026, 6:31 PM ET / 22:31 UTC.

Summary
Current main still classifies every security review needing attention as contributor work and checks that condition before maintainer readiness. The paired implementation PR remains open, so this issue is still necessary until that PR is reviewed and merged or replaced.

Reproducibility: yes. at source level with high confidence: current main deterministically turns every security needs_attention result into unresolved contributor work and then waiting-on-author. The original live PR has since progressed, so the strongest current evidence is the source path rather than that PR's present label state.

Next step
The paired open PR #264 already owns the narrow implementation, so maintainers should review, revise, or land it rather than queue a second repair.

Review details

Best possible solution:

Route only proof-sufficient, correct, finding-free reviews with an explicit recommended accept_risk option to maintainer review, while retaining waiting-on-author for ambiguous or repairable security findings.

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

Yes, at source level with high confidence: current main deterministically turns every security needs_attention result into unresolved contributor work and then waiting-on-author. The original live PR has since progressed, so the strongest current evidence is the source path rather than that PR's present label state.

Is this the best way to solve the issue?

Yes, directionally: #264 proposes a narrow structured exception instead of weakening all security blockers. Maintainers must still approve accept_risk as the owner-acceptance signal.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Maintainers still need to approve whether a recommended accept_risk option is the durable signal distinguishing owner acceptance from a contributor-remediable security defect.

Codex review notes: reasoning high; reviewed against e8e8446c1b2d.

Label changes

Label changes:

• remove clawsweeper:needs-maintainer-review: Current issue advisory state no longer selects this label.

Label justifications:

• P2: The bug can stall a bounded class of security-sensitive PRs in the wrong queue without disrupting core runtime.
• impact:security: The misclassification specifically affects sandbox and security-boundary review ownership.

Evidence reviewed

What I checked:

• Current-main source reproduction: hasUnresolvedContributorWork() treats every securityReview.status === "needs_attention" result as contributor work, and prStatusLabelKind() maps that result to waiting-on-author before checking maintainer readiness. (src/clawsweeper.ts:8940, e8e8446c1b2d)
• Existing focused test surface: The PR-status tests verify waiting-on-author for blocking findings and maintainer readiness for maintainer-only actions, but current main lacks coverage for owner-only security risk acceptance. (test/clawsweeper.test.ts:15723, e8e8446c1b2d)
• Behavior provenance: Blame and symbol history attribute the current contributor-work helper and routing order to commit 666e707; later refactoring retained the relevant condition. (src/clawsweeper.ts:8931, 666e707a8288)
• Paired implementation remains open: The issue is paired with the still-open implementation at Fix PR status routing for security owner review #264; an open closing PR is an implementation candidate rather than grounds to close the issue. (7256492ad862)
• Reported example has since progressed: The original example at fix(agents): materialize sandbox skills for rw sandboxes openclaw#90798 is now merged and currently carries the maintainer-look label, but this does not remove the reproducible unconditional routing rule from ClawSweeper current main.

Likely related people:

• Tak Hoffman: Git blame and symbol history attribute the current contributor-work helper and status-routing order to this contributor's commit. (role: introduced behavior; confidence: high; commits: 666e707a8288; files: src/clawsweeper.ts, test/clawsweeper.test.ts)
• Vincent Koc: Commit b46fde3 later refactored the review-status source and test surface while retaining the relevant behavior. (role: adjacent refactor contributor; confidence: medium; commits: b46fde39d7c5; files: src/clawsweeper.ts, test/clawsweeper.test.ts)
• Dallin Romney: Recent proof-handling work changed nearby maintainer-versus-contributor routing behavior and its test coverage. (role: recent adjacent contributor; confidence: medium; commits: 1eb6e0972ebe; 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]

Opened a small fix PR for this: #264

The PR keeps the safer default for ambiguous/security-fix cases, but routes proof-sufficient, patch-correct PRs with a recommended accept_risk merge-risk option to the existing maintainer-look status instead of waiting-on-author.