Revert "Merge pull request #1095 from hieblmi/claude-review-approve"

[hieblmi]

This PR temporarily reverts the auto-approval so that claude reviews can be triggered again.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[hieblmi]

@claude review this

[claude]

Code Review: PR #1132 — Revert Auto-Approval Workflow

Overview

This PR reverts the changes from #1095, removing the claude-approve CI job and the pull_request_target event trigger from .github/workflows/claude-code-review.yml. The stated goal is to restore Claude review triggering while the auto-approval behavior is temporarily disabled.

The diff is a clean, focused removal of 74 lines — no production code is touched.

---

Intrinsic PR Risk: Low

This is a CI/workflow-only change. No swap logic, state machines, database schemas, fund movement, or cryptographic code is modified. Rollback is trivial (re-apply the reverted commit). Per the project's own risk taxonomy, this classifies as low.

---

Findings

[nit] Missing tracking issue for "temporary" revert

The PR description says this revert is temporary, but there is no linked issue or follow-up task documenting when/how the claude-approve job will be re-added and what the root cause of the triggering problem was. Without a tracking issue, "temporary" reverts have a habit of becoming permanent by default.

[low] Fork PRs will not receive Claude reviews after this change

The claude-review job uses pull_request (not pull_request_target) in its condition, and pull_request events from fork PRs do not have access to repository secrets. This means CLAUDE_CODE_OAUTH_TOKEN will be unavailable for fork-originated PRs, and the review action will silently fail or be skipped. The issue_comment path (triggered by @claude from an OWNER/MEMBER/COLLABORATOR) remains functional and can serve as a workaround.

If fork PR reviews matter, the safe pattern is a split workflow: one job that triggers on pull_request to gather data and passes it as an artifact, and a second job that triggers on workflow_run with access to secrets — avoiding the pull_request_target security footgun entirely.

[positive] Removing pull_request_target is a security improvement

The pull_request_target event runs in the context of the base branch with full secret access, even for PRs from untrusted forks. While the claude-approve job mitigated some risk by not executing fork-provided code (it checks out the base branch and only calls the Claude API), removing this trigger eliminates the attack surface entirely. This is the right call for a project handling Lightning Network fund operations.

---

Summary

Intrinsic PR risk	Low
Highest finding severity	Low
Recommendation	Approve — clean revert, net security improvement

The only actionable suggestion before merging is to open a tracking issue for the re-implementation so the "temporary" intent is captured somewhere durable.