Orphaned `issues: read` permission in `claude.yml` after issues trigger removal

[twistedmelonman]

Non-Blocking Review Concern: Orphaned issues: read permission in claude.yml after issues trigger removal

Source: pre-push whole-codebase review
Location: .github/workflows/claude.yml:19
Date: 2026-05-18

What was flagged

The diff removes the issues event trigger and the issues event condition from the job's if block, but leaves issues: read in the permissions block. The permission is now unused — the workflow no longer handles issues events. This is harmless (excess read permissions don't cause failures or security exposure), but it's misleading to readers of the workflow and leaves the file in a slightly inconsistent state. Consider removing issues: read to keep the permissions block accurate to what the workflow actually needs.

Context

This issue was automatically created from a non-blocking concern identified
during pre-push whole-codebase review. It was flagged for tracking.

---

Created by lib-review-issues.sh

[twistedmelonman]

Verified against the workflow: the issue_comment trigger remains, and GitHub fires issue_comment events for comments on both pull requests and plain issues (not just PRs). When @claude is mentioned in a comment on an actual issue, claude-code-action needs issues: read to fetch the issue body/title/context — so this permission still backs a live code path even though the separate issues: [opened, assigned] trigger was removed. Confirmed the same pattern holds in the reusable claude-assistant.yml workflow in github-workflows, which also declares issues: read for the same reason.

Not removing this permission. Closing as not applicable — the finding is a false positive that didn't account for issue_comment covering issue comments as well as PR comments.