CI/CD, GitHub Actions & Background Agents

Interactive Claude Code assumes a human is present to approve edits and steer. Automation removes that human, so every unattended run needs two things the interactive session gave you for free: non-interactive auth (no browser login) and explicit bounds (so a runaway loop can't burn your CI minutes or your budget).

There are three places an unattended agent can live, and they differ in who supervises it:

The rest of this lesson walks each of these. The throughline: bounded, observable runs. You always know how to stop it, how much it can spend, and where to read its output.

Interactive login opens a browser. A CI runner has no browser, so you pre-mint a long-lived OAuth token and hand it to the runner as a secret.

Generate it once, on a machine where you're logged in:

claude setup-token

This prints a one-year OAuth token scoped to inference. It is printed, never saved to disk — copy it immediately and store it in your CI provider's secret store (e.g. a GitHub Actions repository secret). It requires an active Claude subscription, and it does not work in --bare mode.

In the runner, expose it as the environment variable Claude Code reads in CI:

# .github/workflows/claude.yml
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Claude Code
        run: curl -fsSL https://claude.ai/install.sh | bash
      - name: Run agent
        env:
          CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
        run: |
          claude -p "Summarize what changed in this PR and flag risky diffs" \
            --permission-mode dontAsk --max-turns 6 --max-budget-usd 2.00

Why CLAUDE_CODE_OAUTH_TOKEN and not ANTHROPIC_API_KEY? Both work, but the OAuth token bills against your subscription, while an API key bills your Console account pay-as-you-go. Pick the one that matches how you want to pay. In the auth precedence order, CLAUDE_CODE_OAUTH_TOKEN sits just above interactive subscription OAuth, so setting it is enough — no /login needed.

A headless agent with no human will keep working until it decides it's done — or until it loops. Three flags (all print-mode only, i.e. they require -p) put hard walls around it:

Use them together. dontAsk is the key choice for CI: unlike bypassPermissions (which skips all checks and is only safe in a throwaway container), dontAsk is restrictive — it only permits what you've explicitly allowed and denies everything else, including actions that would otherwise prompt.

Pair dontAsk with an allowlist so the agent can actually do its job:

claude -p "Fix the failing unit tests, then commit" \
  --permission-mode dontAsk \
  --allowedTools "Read" "Edit" "Bash(npm test *)" "Bash(git commit *)" \
  --max-turns 12 --max-budget-usd 3.00 \
  --output-format json

Add --output-format json (or stream-json) when a downstream step needs to parse the result, and --json-schema '{...}' when you want the output validated against a schema.

Background agents are for long tasks you want to fire and check on later from your own machine — not block your terminal waiting. Start one three ways:

• claude --bg "<task>" — start from the shell, print the session ID, return immediately
• Ctrl+B — background the current interactive session (or the running bash command)
• /background (alias /bg) — detach the current session as a background agent

Once running, you manage the fleet from the shell:

All of these are hosted by a single local process: the daemon supervisor. It must be running for background sessions to exist. Two commands keep you out of trouble:

claude daemon status              # supervisor state, version, socket dir, worker count; exits 1 if down
claude daemon stop --any          # stop the supervisor and the sessions it hosts
claude daemon stop --any --keep-workers   # stop supervisor but leave agents running

respawn --all is the trick for picking up an updated Claude Code binary — it restarts every running agent on the new version without losing their conversations.

/autofix-pr turns Claude into a CI watchdog for a branch's pull request. It watches the PR, and when CI fails or a reviewer leaves comments, it pushes fixes to the branch automatically — closing the iterate-on-feedback loop without you babysitting it.

/autofix-pr make sure all checks stay green and address review comments

It has two hard requirements: the gh CLI must be installed and authenticated (so Claude can read PR/CI state and push), and you need Claude on the web (claude.ai), because the watching runs on Anthropic's cloud rather than tying up your terminal.

The complementary command runs locally. When Claude creates a PR, it links the session to that PR automatically. Later, from any machine, resume that linked work:

claude --from-pr 123
# or a full URL — GitHub, GitHub Enterprise, GitLab MR, or Bitbucket PR
claude --from-pr https://github.com/acme/app/pull/123

This pulls up the session(s) tied to that PR so you can keep working with full context, instead of re-explaining the change.

Some agents shouldn't wait for you to start them — a nightly dependency audit, a weekly changelog draft, a morning triage of new issues. /schedule and /routines create and manage cron agents that run on Anthropic's cloud, not your laptop. That means they fire on schedule even when your machine is asleep.

/schedule every weekday at 9am, summarize new issues opened overnight and post a triage list
/routines

/schedule [description] creates a routine from a natural-language schedule + task; /routines lists and manages the ones you've created. Because they run in the cloud, they pair naturally with /autofix-pr and --remote: the work happens server-side, and you check results from any surface — terminal, web, or the desktop app.

The same engine runs in your terminal and at claude.ai. These flags let a single session cross that boundary, so you can start work on one surface and continue on another.

The two directions to keep straight:

• --remote pushes a task out to the cloud (starts fresh on the web).
• --teleport pulls an existing web session in to your terminal.
• --remote-control keeps the session local but mirrors control to the web — useful when you start at your desk and want to nudge it from your phone.

This is what makes the cloud features practical: a /schedule routine or --remote task runs server-side, and when you want to take the wheel, --teleport brings it down to your terminal with full context.