New labeled workflow to trigger Claude Code Review

[theMickster]

🎟️ Tracking

📔 Objective

Because Claude Code doesn't fully support the labeled trigger type for pull requests; we've come up with a creative workaround that we hope will work nicely to add an empty commit to trigger the Review Code workflow by adding and/or removing + adding the ai-review label

[claude]

Claude finished @theMickster's task in 4m 48s —— View job

---

Overall Assessment: No additional issues found

This review examined the new workflow file .github/workflows/trigger-ai-review.yml (88 lines) that triggers Claude Code reviews by pushing an empty commit when the ai-review label is applied. The workflow implements proper security controls including fork protection, error handling with cleanup traps, and scoped token usage.

Code Review Details

No new findings. All significant issues were identified and addressed in the initial review:

• Fork repository checkout security (line 18 check implemented)
• Git operation error handling (set -e, error blocks, and cleanup trap added)
• Credential management (persist-credentials: false with manual git config)

The implementation follows security best practices for GitHub Actions workflows:

• ✓ OIDC-based Azure authentication for secret retrieval
• ✓ Scoped GitHub App token with minimal permissions
• ✓ Explicit cleanup mechanism for git credentials
• ✓ Comprehensive error handling with actionable error messages
• ✓ Protection against fork-based attacks

[claude]

❌ CRITICAL: Workflow will checkout and push to fork repositories, potentially exposing GitHub App credentials

Details and fix

Problem: Using github.event.pull_request.head.repo.full_name means this workflow will checkout fork repositories when PRs come from external contributors. Combined with contents: write permission and the GitHub App token, this could allow malicious actors to:

1. Create a fork
2. Open a PR with the ai-review label
3. Trigger this workflow to push commits to their fork using your organization's GitHub App credentials

Fix: Restrict to same-repository PRs only:

- name: Checkout PR branch
  uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
  with:
    ref: ${{ github.event.pull_request.head.ref }}
    token: ${{ steps.app-token.outputs.token }}
    fetch-depth: 0
    persist-credentials: false

And add a job-level condition:

jobs:
  trigger-review:
    name: Trigger Claude Code Review
    if: |
      github.event.label.name == 'ai-review' &&
      github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-24.04

This ensures the workflow only runs for PRs from branches within the same repository.

[theMickster]

Both security fixes have been applied

[claude]

⚠️ IMPORTANT: Missing error handling for git operations that could fail silently

Details and fix

Problem: Git operations can fail due to network issues, merge conflicts, or branch protection rules. Without error handling, the workflow will fail silently, leaving users confused about why the AI review wasn't triggered.

Fix: Add set -e and error messages:

run: |
  set -e
  git config --local user.email "${_BOT_EMAIL}"
  git config --local user.name "${_BOT_NAME}"
  git commit --allow-empty -m "Claude Code review requested" || {
    echo "::error::Failed to create empty commit"
    exit 1
  }
  git push origin "${_PR_BRANCH}" || {
    echo "::error::Failed to push commit to ${_PR_BRANCH}"
    exit 1
  }
  echo "::notice::Successfully triggered Claude Code review"

The set -e ensures the script exits on any error, and the explicit error messages make debugging easier.

[theMickster]

Implemented error handling

[claude]

❓ QUESTION: How does git push succeed with persist-credentials: false?

Clarification needed

The workflow uses persist-credentials: false which according to the actions/checkout documentation should prevent credentials from being configured in git config. However, the subsequent git push origin command at line 64 requires authentication.

Looking at commit 0d8178e, the push clearly succeeded. How are credentials being provided to git?

Possible explanations:

1. The token parameter at line 53 is being persisted despite persist-credentials: false
2. The behavior of persist-credentials changed in checkout v6
3. There's an implicit credential helper being used

Could you clarify the intended behavior? This affects the security model of the workflow.