fix: grant write permissions to Claude Code workflow

[thomasht86]

Summary

• Update Claude Code workflow permissions from read to write for contents, pull-requests, and issues
• Enables Claude to push to branches and create PRs when triggered via @claude mentions
• By default, only users with write permissions (maintainers) can trigger Claude

Test plan

• Verify workflow runs successfully when triggered
• Test that Claude can push commits and create PRs

🤖 Generated with Claude Code

[claude]

Code Review for PR #40

Summary

This PR updates the Claude Code workflow permissions from read to write for contents, pull-requests, and issues scopes. This enables Claude to perform automated actions like pushing commits and creating pull requests when triggered via @claude mentions.

✅ Positive Aspects

1. Clear Intent: The change is well-documented with inline comments explaining why each permission is needed
2. Proper Conventional Commit: Uses fix: prefix appropriately since this resolves a limitation
3. Minimal Scope: Only changes what's necessary for the feature to work
4. Consistent Formatting: Maintains alignment with other permissions entries

🔒 Security Considerations

Important security notes to consider:

1. Permission Scope: The workflow now has contents: write which allows:

   • Pushing to any branch (including protected branches if not configured properly)
   • Creating/deleting branches
   • Modifying repository files

   Recommendation: Ensure branch protection rules are configured on main and any other critical branches to require reviews and status checks even for actions with write permissions.

2. Trigger Mechanism: Currently, any comment containing @claude triggers the workflow. The conditional logic (if:) filters by comment content but not by user permissions. While the PR description mentions "only users with write permissions can trigger Claude," this is not enforced in the workflow file itself.

   Recommendation: Consider adding explicit permission checks in the workflow:

   if: |
     (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude') && 
      (github.event.comment.user.permissions.write || github.event.comment.user.permissions.admin)) ||
     ...

   Or document that repository settings must be configured to restrict who can comment.

3. API Key Exposure: The workflow uses secrets.ANTHROPIC_API_KEY. Ensure this secret is properly restricted and rotated periodically. With write permissions, a compromised workflow could potentially exfiltrate this key.

4. Comparison with Other Workflows:

   • The main CI workflow (CI.yml) uses contents: read at the top level, with contents: write only granted to specific jobs that need it (e.g., release, benchmark)
   • The claude-code-review.yml workflow maintains read-only permissions (contents: read, pull-requests: read)

   This is the most permissive workflow in the repository, which may be necessary for its functionality but warrants extra scrutiny.

📋 Best Practices

1. Principle of Least Privilege: Consider if all three write permissions are needed for all use cases:

   • Could some @claude commands work with read-only access?
   • Could you use job-level permissions to grant write access only when needed?

2. Audit Trail: With write permissions, ensure the workflow actions are clearly logged. The commit message template includes Claude attribution which is good.

3. Documentation: Consider adding a security section to the repository docs explaining:

   • Who can trigger Claude actions
   • What permissions Claude has
   • Branch protection requirements
   • How to audit Claude's actions

🧪 Testing Recommendations

From the PR body test plan:

• ✅ Verify workflow runs successfully when triggered
• ✅ Test that Claude can push commits and create PRs
• Add: Test that unauthorized users cannot trigger the workflow (if intended)
• Add: Test Claude's behavior on protected branches
• Add: Verify that Claude respects branch protection rules

📊 Code Quality

• Formatting: ✅ Clean, aligned comments
• Consistency: ✅ Matches workflow style
• Documentation: ✅ PR description clearly explains the change

⚠️ Potential Issues

1. No user permission validation in the workflow itself (relies on GitHub repo settings)
2. Very broad permissions - could be scoped to specific jobs if only some @claude commands need write access
3. No rate limiting or abuse prevention visible in the workflow

🎯 Recommendation

Conditional Approval - The change is functionally correct for enabling Claude's enhanced capabilities, but I recommend:

1. Before merging: Add explicit permission checks to the if: condition or document why GitHub's default settings are sufficient
2. After merging: Document the security model and add branch protection rules if not already present
3. Consider: Job-level permissions if only specific Claude actions need write access

Example Enhancement

jobs:
  claude:
    if: |
      (
        (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
        ...
      ) &&
      (
        github.actor == github.repository_owner ||
        contains(fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'), github.event.comment.author_association)
      )
    # ... rest of job

---

Overall, this is a reasonable change for enabling Claude's full capabilities, but the security implications should be carefully considered given this becomes the most privileged workflow in the repository.