Claude Code in GitHub Actions for UK indie hackers: the auto-fix CI workflow that fixes failing tests while you sleep

Here is a familiar Tuesday for a UK indie hacker. You push a branch at 17:00, CI goes red, you are on a train, and the fix waits until you are back at your desk at 19:30. Two and a half hours of dead time on a one-line type error. Multiply that across a week of small breakages and you have lost most of an evening to babysitting a test runner.

Claude Code in GitHub Actions removes that. With the official anthropics/claude-code-action, you can run Claude Code as an autonomous agent inside your CI pipeline. When a build goes red, Claude reads the failure output, traces the root cause across files, writes a fix, and opens a pull request — before you have even seen the notification. You review the PR when you are back, instead of starting the debugging from scratch.

This is the UK builder's guide to wiring it up. The quickstart. A complete, copy-paste auto-fix workflow. The cost controls that keep it cheap, priced in GBP. And the security guardrails that stop an autonomous agent in your CI becoming a liability.

The quickstart: /install-github-app

The fastest route in is a single command. Inside a Claude Code terminal session, in your project, run:

/install-github-app

It installs the Claude GitHub App on your repository, configures the repository secret it needs (your Anthropic API key, stored as ANTHROPIC_API_KEY), and drops a starter workflow file into .github/workflows/. For a UK indie hacker who is a direct API user, this is the whole setup — three or four minutes, and you have a working @claude integration.

Once it is installed, you get the baseline behaviour for free: mention @claude in any issue or pull request comment, and the agent analyses the code, and can implement features, fix bugs, or post a review — following your repo's CLAUDE.md standards as it goes.

The auto-fix workflow, in full

The starter workflow is reactive — it waits for an @claude mention. The piece that actually saves your Tuesday evening is proactive: a workflow that fires automatically when CI fails. Here is a complete one. Save it as .github/workflows/claude-auto-fix.yml:

name: Claude Auto-Fix CI

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

# Only act on failures, and never run two fixes on one branch at once
jobs:
  auto-fix:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    concurrency:
      group: auto-fix-${{ github.event.workflow_run.head_branch }}
      cancel-in-progress: true
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.workflow_run.head_branch }}

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          model: claude-sonnet-4-6
          max_turns: 15
          prompt: >
            The CI workflow failed on this branch. Read the failing
            job's logs, find the root cause, and write the smallest
            correct fix. Run the test suite locally to confirm the
            fix works. Then open a pull request with a clear British
            English description of what broke and what you changed.
            Do not change unrelated code. Do not touch the billing
            or auth modules without flagging it in the PR description.

Wire it to trigger off your existing CI workflow (rename the string in workflows: to match yours). When CI goes red, this fires, Claude reads the actual failure logs — not just the failing assertion, the why — fixes it, confirms the fix, and opens a PR. You wake up to a green PR waiting for review instead of a red build waiting for you.

The key detail that makes this worth having: Claude looks at what broke and why, not just what the failing assertion says. A junior dev given only the assertion line patches the symptom. Claude given the full log traces it back — which is the difference between a real fix and a papered-over one.

Cost control: keeping it cheap in GBP

An autonomous agent in your CI is a recurring cost, so it has to be a controlled one. Four levers, and used together they keep an indie-hacker auto-fix setup in the low single-digit pounds per week.

1. Use Sonnet, not Opus, as the CI default. Sonnet is the right model for routine CI fixes — type errors, lint failures, broken tests, the bread-and-butter breakages. It runs at roughly 60% less cost than Opus and handles these with equivalent reliability. The model: line in the workflow above pins it. Opus is for when you are personally doing deep architecture work, not for the CI janitor.

2. Cap max_turns. The max_turns: 15 line is a hard ceiling on how many steps the agent takes before it stops. A genuine CI fix almost never needs more than a handful of turns. The cap means a confused run fails cheap instead of churning.

3. Filter paths. Add a paths: filter to the trigger so the auto-fix workflow only fires for failures touching your application code — not for a typo in the README or a tweak to the workflow file itself. Every run you do not start is a run you do not pay for.

4. Use the concurrency group. The concurrency block in the workflow cancels an in-progress fix if a newer one starts on the same branch. Without it, three quick pushes can spawn three overlapping fix runs. With it, only the latest matters.

For a typical UK micro-SaaS — a handful of red builds a week, each a small fix on Sonnet — this lands in the low single-digit pounds per week. The comparison that matters is not pounds-versus-zero; it is pounds-versus-the-evenings you stop losing to babysitting CI.

Security guardrails: an autonomous agent needs a short leash

A workflow that can write to your repo and open PRs is a real surface. Four guardrails, none optional:

• Least-privilege permissions. The workflow above grants exactly contents: write and pull-requests: write — nothing more. It cannot touch repository settings, secrets, or other workflows. Never grant the auto-fix job blanket write-all.
• It opens PRs, it does not push to main. The agent's output is a pull request you review, not a direct commit to your default branch. The human review step is the safety net — keep it.
• No secrets in logs. Claude reads CI logs to find the root cause. Make sure your CI does not print secrets into those logs in the first place — mask them at the workflow level. An agent that reads logs will read whatever is in them.
• Scope the prompt. The prompt in the workflow explicitly tells the agent not to touch billing or auth modules without flagging it. For a UK micro-SaaS, the money-handling and auth code is exactly where you want a human in the loop — say so in the prompt.

This pairs with the local guardrails on your own machine. Hooks catch dangerous commands and leaked secrets in your interactive sessions (see the Claude Code hooks guide); plan mode keeps the agent from one-shotting a risky refactor (see the plan mode guide). The CI auto-fix workflow is the same safety thinking extended to the pipeline — least privilege, human review, scoped instructions.

What it is good at, and what it is not

Be honest about the boundary. Claude Code auto-fix in CI is excellent at the high-frequency, low-stakes breakages: type errors, lint failures, a test broken by a refactor, a missing import, an outdated snapshot. These are the failures that eat your evenings precisely because they are small enough to be annoying and frequent enough to add up.

It is not a replacement for thinking through a genuine design problem. If CI is red because a feature is fundamentally wrong, the auto-fix workflow will produce a PR that makes the test pass — which is not the same as making the feature right. Read the PRs. The workflow buys back your time on the trivial failures so you have more of it for the ones that actually need you.

Want a data-backed UK business idea every week? Free reports drop every Thursday — keyword volumes, SERP analysis, builder prompts. Browse the latest free report on IdeaStack.

---