[erikdarlingdata]

Follow-up to #2311, addressing the review's residual finding that landed minutes before the merge: errfile=$(mktemp) and err=$(cat ...) were themselves plain assignments under set -e, so the helper's own plumbing could still kill the step with none of the warning/summary/exit-0 handling it exists to provide.

Now: a failed mktemp degrades to /dev/null (stderr detail is lost, the verdict path survives — commented in place), the cat is || true-tolerant, and the rm never fires at /dev/null. Verified with a four-case stub matrix: gh-fails, noisy-success, mktemp-fails-with-clean-gh, and both-fail — every path either reaches the verdict or exits 0 with the warning; none can die raw. YAML parses and the extracted script passes bash -n.

🤖 Generated with Claude Code

[claude]

Reviewed the diff in .github/workflows/claude-review-guard.yml (this PR touches nothing else — no SQL, no Lite/Darling app code, so parity/missing-index concerns don't apply here).

Traced the four failure combinations by hand against the new code in lookup():

• mktemp fails, gh api succeeds: errfile degrades to /dev/null (the mktemp 2>/dev/null || echo /dev/null fallback always exits 0, so the assignment can't trip set -e). The success-path cleanup [ "$errfile" != /dev/null ] && rm -f "$errfile" || true correctly skips rm on /dev/null.
• mktemp fails, gh api fails: errfile=/dev/null, stderr from the failed gh api call is discarded. cat /dev/null succeeds trivially (empty err), so the warning message falls back to ${err:-$LOOKUP_OUT} — matches the PR description's "stderr detail is lost, verdict path survives."
• mktemp succeeds, gh api fails: cat "$errfile" 2>/dev/null || true can no longer kill the step even if the temp file vanished out from under it; rm -f still runs since errfile != /dev/null.
• mktemp succeeds, gh api succeeds: unchanged behavior, temp file is cleaned up.

In all four cases the exit status feeding into set -e at each assignment is now always 0 (the || true / || echo ... fallback in each case guarantees it), so the plumbing itself can no longer produce the raw kill this PR is fixing. I don't see a case where the guard could still die on its own plumbing.

One minor observation, not a defect: the [ "$errfile" != /dev/null ] && guard is technically redundant with the trailing || true (a bare rm -f "$errfile" || true would already survive a permission error on /dev/null), but keeping it avoids ever invoking rm against /dev/null at all and matches the "commented in place" intent described in the PR body — I'd leave it as is.

No correctness, security, or performance issues found. LGTM.