Action exits with subtype:success + is_error:true ~15-25s in, before reviewing (intermittent)

Summary

On /code-review (comment-mode) runs, the action intermittently fails ~15–25s after the "Run Claude Code Action" step with:

"is_error": true,
##[error]Claude result reported subtype success with is_error:true (run did not complete successfully)
##[error]Action failed with error: Claude execution failed: result is_error:true
##[error]Process completed with exit code 1.

The claude-execution-output.json carries a result record with subtype: success and is_error: true, and no review is performed — no subagents aggregate, no findings, no summary comment. The fast fail suggests the agent errors on start-up, before the review runs.

Version

anthropics/[email protected] (pinned SHA 8251c103ac8c1d761882c86aba1412c7f583c844), GitHub-hosted ubuntu-latest, WIF auth, --model an Opus-class model.

It is intermittent, not deterministic

The same workflow and action version succeeds on some runs and fails on others in the same repository, across multiple PRs and consecutive pushes — a config/version break would be 100%. This points to a transient in the agent's execution (e.g. a start-up/model/transport error) being surfaced as is_error: true with subtype: success.

It is not the --tsconfig-override Bun bug

We do not pass --tsconfig-override (the known "Internal error: directory mismatch for tsconfig.json" Bun issue is separately avoided per the action's own guidance). The failure above occurs without it.

Impact

Fail-closed review gates that require a machine verdict correctly stay red (no verdict = no merge), but a valid PR cannot obtain a verdict until a retry happens to land on a clean run. It is hard to distinguish "the action never executed" from "the review ran and failed" downstream, because both surface as a failed run.

Questions / requests

1. Is subtype: success + is_error: true a known transient (rate-limit / model start error / transport) rather than a review outcome?
2. Could the action surface the underlying error cause in the result (or logs) so consumers can tell a failed start from a failed review?
3. Could a failed start (no aggregation produced) be retried internally, or at least flagged distinctly from a completed-but-failed review?

Happy to provide additional non-sensitive execution-output excerpts. (Source repo is private, so run URLs are not publicly reachable.)