You will need
- A GitHub repository with a test suite that runs in CI
- Claude Code GitHub Actions, with an Anthropic API key or a Claude subscription token stored as a GitHub secret (usage is billed)
- GitHub Actions minutes (included amounts depend on your GitHub plan)
- Branch protection on your main branch
You will end up with
- One pull request per fix, each on its own branch
- Nothing merged without a person's approval
Protect the main branch first
Turn on branch protection for main: require pull request reviews before merging, and restrict who can push. This is what actually stops an agent from merging, not the token alone.
Give the workflow the least access it needs
Install Claude Code GitHub Actions (the action is open source, MIT). Store the API key as a GitHub secret, never in the repo. In the workflow, set GITHUB_TOKEN permissions to the minimum (contents and pull requests write only). GitHub recommends fine-grained tokens over classic ones if you use a personal token.
Sources: Claude Code docs: GitHub Actions · anthropics/claude-code-action on GitHub · GitHub Docs: Use GITHUB_TOKEN for authentication · GitHub Docs: Managing your personal access tokens
Schedule the run
Add a schedule trigger with cron syntax (it runs in UTC unless you set a time zone). With a prompt, the Claude Code action runs in automation mode on a cron schedule. It has no shell access until you grant tools with --allowedTools in claude_args; allow only what running tests and editing code needs. You can also set allow/deny permission rules in Claude Code settings. Set --max-turns to cap cost. Test output and code comments can carry prompt injection, so keep tool access narrow.
Sources: GitHub Docs: Events that trigger workflows (schedule) · Claude Code docs: GitHub Actions — Run on a schedule · Claude Code docs: Settings (permissions) · Claude Code docs: Security
Prompt Run the test suite with [TEST COMMAND]. For each failing test, up to [N]: create a branch named fix/<test-name>, make the smallest change to the code under test that makes it pass, run the full suite again, and open a pull request explaining the cause. Never edit, skip or delete a test to make it pass. Never change CI config, dependencies or secrets. If you are not confident, open an issue instead of a pull request.
Review the pull requests in the morning
A person reviews and merges. Close any pull request that changes a test to make it pass, or touches files outside the fix.
Sources: GitHub Docs: About protected branches
Human checkpoint. A person approves this step before the agent goes further.
Questions
What does this use case do?
A scheduled GitHub Actions run lets Claude Code try to fix failing tests on a branch and open a pull request. A person reviews every change in the morning.
How is this use case sourced?
Documented (each step backed by official docs; not tested by us). It lists 8 named sources.
When was this use case last updated?
Last updated Oct 31, 2026. It lists 8 named sources. Published use cases are listed in /feed.xml. The use case does not store a separate last-verified date.