Claude Code on your pull requests
The Claude Code action runs the agent inside a GitHub workflow, either waiting for an @claude mention or running a prompt on any event. Setup is short; the access and secret choices are where it goes wrong.
Two ways to run it
anthropics/claude-code-action@v1 runs Claude Code inside a workflow. How it behaves depends on one input.
With no prompt, it is interactive. It reacts when someone writes @claude in a pull request or issue, and does what that comment asks.
With a prompt, it runs in automation mode on whatever event you attach it to: a pull request opening, a label, a cron schedule. Nobody asks. The workflow file is the request.
It is the same agent you run locally, working through the GitHub runner instead of your machine.
Setting it up
The quick route is /install-github-app inside Claude Code. It works on github.com only, needs gh to be logged in, and needs admin rights on the repository.
Then the workflow needs a credential. Two secrets work: ANTHROPIC_API_KEY, or CLAUDE_CODE_OAUTH_TOKEN, which you create with claude setup-token. The choice matters for teams. An API key suits a secret shared across an organization. An OAuth token belongs to one person's subscription, so a whole team running on it is running on one person's account.
If you would rather hold no long-lived secret at all, workload identity federation is supported. It uses inputs such as anthropic_federation_rule_id and needs the id-token: write permission. Cloud providers are switched with use_bedrock, use_vertex or use_foundry, all through OIDC.
Your whole team will trigger the action. Which credential fits better, and why?
Passing options through
claude_args takes any CLI flag, which is where the limits from the headless lesson come back. For example --max-turns 5 stops a run that wanders, and --model picks the model. Treat this field as the place you bound the job.
CLAUDE.md is read on every run, so a long one is paid for on every pull request. Keep it short.
Who can trigger it
The user who triggers the action needs write access to the repository. Bot actors are rejected unless you list them in allowed_bots.
Scheduled runs have a subtle rule: they are attributed to whoever last edited the cron line. If that person was a bot, the run is rejected unless the bot is allowed. Also, GitHub disables schedules in public repositories after 60 days without activity, so a quiet repo's nightly job can stop without any error from Claude.
What to put in the prompt
Because automation mode has no human to correct it, the prompt carries the whole task and its boundary. A review prompt that works says what to look at, what to ignore and where to stop, for example: review the diff for missing error handling, comment only on lines that changed, do not edit files. An open-ended prompt on a cron schedule is the same problem as an unbounded script loop.
Claude pushed a commit but your CI checks did not run. What is the likely cause?
Chapter complete
You've finished chapter 3 of 6 in Parallel and unattended.
Claude Code has three places to run something repeatedly: cloud routines, Desktop scheduled tasks and the in-session /loop. They differ in where they run, how often they can fire and what survives.
Next chapter