claude-code-review still republishes a raw gh pr comment invocation as the review body (--edit-last variant, gha#312 regression)

[dem-extra1]

Summary

The exact failure mode #312 described — claude-code-review.yml's "Post review comment" step republishing the reviewer's own raw shell command instead of the review text — recurred on PR #380, in a form the unwrap_posted_body fix from #318 doesn't catch.

Evidence

Seen on Morrison-Lab/gha#380, run 30530903965.

The reviewer initially posted a placeholder comment (test-can-i-post, then edited to placeholder - real review incoming), then used a Bash tool call to edit that same comment into its real review via:

gh pr comment 380 --repo Morrison-Lab/gha --edit-last --body '## Code review
...
**Verdict: Ready for merge** ...'

That edit worked correctly — the claude[bot] comment ended up showing the rendered review text, verdict included.

But separately, the workflow's own "Post review comment" step (which extracts review_text_file from the execution output and reposts it via gh pr comment as github-actions[bot]) posted the literal command above, verbatim, as a new comment — not the review text it wrapped. So the PR again ended up with the review twice: once rendered correctly (claude[bot]), once as an unrendered shell command (github-actions[bot]) — the same duplicate-and-garbled pattern #312 reported.

Why #318's fix doesn't catch this

#318's unwrap_posted_body in check-review-execution.sh specifically matches the heredoc form:

gh pr comment N --body "$(cat <<'EOF'
...
EOF
)"

This occurrence uses a different shape entirely — --edit-last --body '...' with a single-quoted literal string, no heredoc at all. The regex that extracts heredoc contents has nothing to unwrap here, so the whole command (including --edit-last) passes through as the "review text" unchanged.

Suggested fix

Generalize unwrap_posted_body (or add a sibling case) to also recognize a plain gh (pr|issue) comment ... --body '...' / --body "..." invocation (with or without --edit-last) and extract the quoted argument, not just the heredoc form. Both shapes are "the reviewer posted its own comment via Bash instead of returning prose," so the fix should probably key on "this Bash tool_use block's command matches gh (pr|issue) comment" generally and try several known argument shapes, rather than only the heredoc one.

Worth adding a regression fixture with this --edit-last --body '...' shape alongside the existing heredoc fixture, so both variants are pinned.

Related

• claude-code-review can post the reviewer's raw gh pr comment heredoc instead of the review body #312 (closed as fixed by Fix claude-code-review republishing a raw gh pr comment as the review body #318) — same underlying class of bug, narrower fix.

[d-morrison]

Root cause: gh pr comment was never actually denied

Working on this. Digging into the duplicate on Morrison-Lab/ai-config#1104 (claude[bot] full review + github-actions[bot] re-post), the root cause turns out to be more fundamental than the unwrap_posted_body heredoc handling, and it explains why #312/#318/#381 keep recurring in new variants.

The reviewer's gh pr comment self-post channel was documented as blocked but never wired up. Three places assert it is denied:

• run-claude-review-attempt/action.yml header: "gh pr comment ... is deliberately NOT granted ... letting the plugin self-post would risk duplicate or uncontrolled comments"
• check-review-execution.sh: "a Bash gh pr comment ... call is NOT in ... allowedTools (deliberately) ... so any such call ... was necessarily DENIED"
• gha CLAUDE.md's run-claude-review-attempt paragraph: same claim

But the actual --disallowedTools list denies only git-write, python3 -m, and the async tools -- not gh pr comment. And the upstream code-review plugin's command frontmatter re-grants it (allowed-tools: ..., Bash(gh pr comment:*), ...). So the agent successfully self-posts the ## Code review summary as claude[bot], and the workflow's "Post review comment" step re-posts the extracted text as github-actions[bot] -- the duplicate. The --edit-last / raw-heredoc variants this issue and #312 chase are all downstream of that same un-denied tool.

Proposed fix (makes the whole class moot rather than patching unwrap_posted_body again): actually add Bash(gh pr comment:*) to --disallowedTools, and reword the reviewer prompt so it outputs its review (findings not tied to a line, plus the ### Verdict) as its final message instead of posting a top-level comment -- the workflow already posts on its behalf, with the run-link header, collapse-as-outdated, and cost linkage the self-post lacks. Inline comments (the inline-comment tool) are untouched. Then the agent never calls gh pr comment, so there is never a raw command to republish and never a second top-level comment.

Opening a PR shortly.