review: a Claude error result is a red run, and it pages - #1238
Conversation
anthropics/claude-code-action reports success even when Claude's own result is an error. 2026-09-02 05:15 UTC: is_error true after 11 s (the shared OAuth token at its spending cap), the run went green, and #1237 sat unreviewed with nothing to show for it. The fetch workflow already verifies its outcome and pages on failure; the review workflow had neither. Now: grep the execution file for is_error, fail the step, and send the same Bark push the fetch side sends. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1322df8ffc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if: steps.claude-review.outcome == 'success' && steps.claude-review.outputs.execution_file != '' | ||
| run: | | ||
| f="${{ steps.claude-review.outputs.execution_file }}" | ||
| if grep -Eq '"is_error":\s*true' "$f"; then |
There was a problem hiding this comment.
Restrict the check to the final result event
When Claude encounters a recoverable tool error and then completes the review, the execution log still contains a tool-result block with is_error: true; the SDK documentation explicitly defines this flag for tool results (content/en/docs/claude-code/agent-sdk/todo-tracking.md:210-215), while the action documentation describes execution_file as the entire event log and locates the final outcome by selecting an entry whose type is result (content/github/claude-code-action/base-action/README.md:366-377). Grepping the whole file therefore makes such successful reviews exit 1 and send a false Bark page. Parse the final type == "result" event and test its is_error field instead.
Useful? React with 👍 / 👎.
What went wrong
Today at 05:15 UTC the day-shift review of #1237 ran for 11 seconds, four turns, and Claude's result was
"is_error": true(the shared OAuth token was at its spending cap; the hn-digest curate step hit the same wall 17 minutes later and, using the fork of the action, failed properly).anthropics/claude-code-action@v1.0.168reported the step as success, the run went green, and #1237 sat with no review, no merge, no comment, no page. Eight green review runs in a row; this one produced nothing and looked the same.The change
Two steps after the review, mirroring what
fetch-claude-docs.ymlalready does for the night shift:execution_filefor"is_error": trueand exit 1 with the result text in the log. Skipped when the review step itself was skipped ([skip-review],[WIP]) since there is no execution file.The detection was checked against the error shape from today's log. The Bark step could not be exercised without the secrets; it is the fetch workflow's step with a different title.
Nothing about the review prompt or its permissions changes.