feat: escalate unposted findings to issues and record wrap-up failures in the step summary - #61
Merged
Merged
Conversation
…s in the step summary Add escalate_findings_to_issues (review mode, off by default): when the turn-limit wrap-up step fails to post its own closing reply, a narrowly scoped follow-on judges each Blocker/Should-fix finding and opens or updates one issue per finding, deduped by a stable marker, rather than bundling every finding from a run into a single catch-all issue. Its allowlist holds only issue read/write tools, nothing the wrap-up call itself could already do. Requires issues: write, which review mode's reusable workflow does not request, so this only takes effect through the direct form (examples/direct/claude-review-with-issue-escalation.yml). Independent of that input, always write the wrap-up's own last result text to the job's Step Summary when the wrap-up step fails. This needs no token scope at all, so it fires for every consumer regardless of escalate_findings_to_issues, and it previously left that content visible only as raw JSON in a job log nobody reads by default. A wrap-up failure that escalation successfully turns into a recorded issue is treated as handled rather than as an unseen failure, so it no longer flips the job to failure on its own.
Mearman
marked this pull request as ready for review
September 11, 2026 10:22
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
❌ Claude's run did not complete (outcome: failure). View job run |
|
🗜️ Headroom context compression
|
|
🎉 This PR is included in version 1.11.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this adds
When the turn-limit wrap-up step runs and itself fails to post its own closing reply -- typically because that write was blocked, or the pull request/issue it was about had already merged or closed underneath it -- two things now happen instead of the content silently existing only in a raw job log:
escalate_findings_to_issues, review mode, off by default): a narrowly scoped follow-on resumes the same session and judges, finding by finding, whether anything already found is severe enough (Blocker or Should-fix, never a Nit) to open or update a GitHub issue for -- one issue per distinct finding, deduped by a stable marker, never one bundled issue for a whole run. Requiresissues: write, which review mode's reusable workflow does not request, so it only takes effect through the direct form (examples/direct/claude-review-with-issue-escalation.yml).A wrap-up failure that escalation successfully turns into a recorded issue is treated as handled rather than as an unseen job failure.
Why
Confirmed live on a consuming repository: a review's wrap-up call correctly determined a pull request had already merged, re-verified every finding from its prior review was fixed in the merged code, and then failed outright trying to post that conclusion -- both
gh pr commentandmcp__github__add_issue_commentwere blocked pending a permission grant no one was present to give in a headless run. The run showed a plain red X with no indication of why, and the actual content (a clean bill of health) never reached anywhere a human would look.Validation
npm run format:check/npm run lint/npm run typecheckall pass.action.yml's composite-action steps validated via the syntheticworkflow_callwrapper +actionlinttechnique described in this repo's own README (issue count unchanged from the pre-change baseline: 26 pre-existing warnings, 25 after -- no new findings in either new step).