Use reusable Claude Code workflow from test-infra

[ZainRizvi]

Summary

Replaces the inline Claude Code workflow with the centralized reusable workflow from pytorch/test-infra.

What changes

• Drops the hardcoded pilot user allowlist (20 users) in favor of author_association checks + API-level write access verification
• Removes pull_request_review_comment trigger (security fix, per [Fix] Revert support for pull request review comments in Claude Code review workflow pytorch#176652)
• Passes lintrunner install via setup_script input (preserving the existing setup)

What stays the same

• Same security model (org gate, write access check, bot allowlist)
• Same lintrunner setup (pip install lintrunner==0.12.5 && lintrunner init)
• Same model, settings, and usage metrics upload

Depends on pytorch/test-infra#7810 which added the reusable workflow.

Test plan

• Reusable workflow tested end-to-end on pytorch/ciforge
• Verify @claude triggers correctly after merge

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/tutorials/3788

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit bfb4f63 with merge base f380781 ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[ZainRizvi]

@claude review for consistency between original and new behaviors

[claude]

Claude finished @ZainRizvi's task in 3m 17s —— View job

---

Review: Consistency between original and new behaviors

• Read the current workflow file on this branch
• Read the original workflow file from origin/main
• Attempted to read the reusable workflow from pytorch/test-infra (blocked by sandbox — see caveat below)
• Compare triggers, permissions, security model, and setup
• Post review findings

---

Caveat

I was unable to fetch the reusable workflow at pytorch/test-infra/.github/workflows/_claude-code.yml due to sandbox network restrictions. The analysis below is based on comparing the original inline workflow against the new caller file and the PR description. Items I cannot verify from the reusable workflow's internals are flagged.

---

Trigger events

Behavior	Original	New
issue_comment (created)	Yes	Yes
pull_request_review_comment (created)	Yes	Removed
issues (opened)	Yes	Yes

The removal of pull_request_review_comment is an intentional change per the PR description (security fix, pytorch/pytorch#176652). This is a behavioral difference but a desired one.

Verdict: Consistent with stated intent. No accidental omission.

---

Permissions

Permission	Original (job-level)	New (workflow-level)
contents: read	Yes	Yes
pull-requests: write	Yes	Yes
issues: write	Yes	Yes
id-token: write	Yes	Yes

The permissions are identical in content. The new file declares them at workflow level instead of job level. Since the reusable workflow is called with secrets: inherit, it will inherit these permissions. This is correct — reusable workflows receive the permissions of the caller.

Verdict: Consistent.

---

Access control / security model

Behavior	Original	New
Org gate (pytorch)	github.repository_owner == 'pytorch' in if:	Delegated to reusable workflow (⚠️ cannot verify)
User allowlist	Hardcoded 20-user JSON array	Replaced by author_association + API write-access check (⚠️ cannot verify)
@claude mention check	Explicit contains() conditions per event type	Delegated to reusable workflow (⚠️ cannot verify)
Bot allowlist	allowed_bots: "*" (all bots)	Delegated to reusable workflow (⚠️ cannot verify)

The PR description states the reusable workflow uses author_association checks + API-level write access verification. This is a more scalable approach than a hardcoded user list, but it's a behavioral change: users who had explicit allowlist access but lack write permissions to the repo would lose access, and conversely, any user with write access gains it without being on an explicit list.

Verdict: Deliberate change. Worth confirming that all 20 original pilot users have write access to pytorch/tutorials, or are covered by the new author_association criteria.

---

Setup / lintrunner

Behavior	Original	New
Python setup	actions/setup-python@v5 with Python 3.12	Delegated to reusable workflow (⚠️ cannot verify if it sets up Python)
Lintrunner install	pip install lintrunner==0.12.5 && lintrunner init	Passed via setup_script input — same commands

The setup_script content is identical to the original install step. However, the original workflow explicitly set up Python 3.12 via actions/setup-python@v5 before running lintrunner install. If the reusable workflow does not set up Python or uses a different version, the pip install in setup_script might behave differently.

Verdict: The lintrunner commands are consistent. ⚠️ Verify that the reusable workflow sets up a Python environment before running setup_script, or that the default runner Python is sufficient.

---

Runtime configuration

Behavior	Original	New
Runner	ubuntu-latest	Delegated to reusable workflow
Timeout	60 minutes	Delegated to reusable workflow
Environment	bedrock	Delegated to reusable workflow
AWS OIDC credentials	Explicit aws-actions/configure-aws-credentials@v4 step	Delegated to reusable workflow
Claude action	izaitsevfb/claude-code-action@forked-pr-fix	Delegated to reusable workflow
Model	global.anthropic.claude-opus-4-6-v1	Delegated to reusable workflow
Settings	{"alwaysThinkingEnabled": true}	Delegated to reusable workflow
use_bedrock	"true"	Delegated to reusable workflow
Usage metrics upload	Explicit pytorch/test-infra/.github/actions/upload-claude-usage@main	Delegated to reusable workflow

All of these are now internal to the reusable workflow. The PR description says "Same model, settings, and usage metrics upload" which is the correct intent.

Verdict: Cannot independently verify, but the reusable workflow is designed to be the canonical implementation for all pytorch repos, so these should be standardized.

---

Summary of findings

1. No accidental behavioral regressions detected in what I can verify from the caller file.
2. Intentional changes are well-documented: removal of pull_request_review_comment trigger and replacement of hardcoded allowlist with dynamic access checks.
3. Three items to verify in the reusable workflow (which I couldn't fetch):
   • Python environment setup before setup_script runs
   • Org gate (pytorch check) is present
   • @claude mention filtering is present
4. Minor note: The allowed_bots: "*" setting from the original is not passed to the reusable workflow. If the reusable workflow defaults to a more restrictive bot policy, pytorch-auto-revert[bot] (which was on the original allowlist) may lose access.

Overall this looks clean and the new file is dramatically simpler. The consistency is maintained for everything the caller can control, and the behavioral details are correctly delegated to the centralized workflow.

---

[sekyondaMeta]

Thanks @ZainRizvi