What is “Background Claude”? A field guide to the term

Background Claude is the umbrella term for running Claude Code without a human watching every step — headless, scheduled, or agent-triggered. The phrase covers three concrete surfaces of Claude Code usage that share one common property: nobody is in the terminal pressing enter. This post is a short field guide to what the term means, where it came from, and how it maps onto the Claude Code features you already use.

The short definition

Background Claude (n.): any usage of Claude Code where the session runs non-interactively — without the TUI, without human approval of each tool call, and usually without any real-time human observation. Includes claude -p headless calls, scheduled cron runs, and full background agents triggered by webhooks.

Where the term comes from

The phrase surfaced in developer communities roughly in tandem with Claude Code's -p(print) flag becoming a staple for scripting. Once you can pipe a prompt into Claude and get a response back without launching a TUI, “running Claude in the background” becomes a literal technical description — a Claude session that runs while you're doing something else. By late 2025 and early 2026 the phrase had compressed into the noun Background Claude, the same way “continuous integration” compressed into CI.

Google Trends confirms the trajectory: search interest for background claude jumped 18× year-over-year into Q1 2026, with peak interest the week Anthropic shipped native scheduled tasks and loop support inside Claude Code.

The three levels of Background Claude

In practice, everyone who says “background claude” means one of three things. They're layered — each level builds on the one below.

Level 1: Headless runs

One claude -p "<prompt>" call. Claude reads the prompt, does its work, writes output to stdout, exits. This is the atom every other pattern is built from.

claude -p "summarize the changes in the last git diff" \
  --output-format text \
  --permission-mode dontAsk \
  --max-turns 5 \
  --max-budget-usd 1

This is the territory covered by the headless guide and the --bare mode post. Single-shot, stateless, scriptable.

Level 2: Scheduled runs

The same claude -p call, but on a timer. Cron, GitHub Actions schedule, or Claude Code's native /loop command. Every invocation is still stateless, but now the schedule itself is state you have to manage. Runs can pile up, overlap, or miss their window.

# every night at 3am, run the nightly sweep
0 3 * * * cd ~/repo && \
  claude -p "check for new security advisories" \
  --output-format json \
  --max-turns 10 \
  --max-budget-usd 2 \
  > ~/logs/nightly-$(date +\%F).log

Covered in the scheduled guide. You can get 3-5 scheduled jobs working reliably on a single machine. Beyond that you start hitting worktree conflicts, cron drift, and no audit trail.

Level 3: Background agents

Event-triggered, not time-triggered. A Linear issue label changes, a GitHub PR comment mentions @claude, a Slack message arrives — and a new isolated Claude Code session spins up, reads the context, does the work, posts the result back to the triggering system.

Linear issue labeled "agent-ready"
  ↓ webhook
  ↓ spawn isolated git worktree
  ↓ claude -p <issue body>
      --allowedTools Bash,Edit,Read
      --max-budget-usd 5
      --output-format stream-json
  ↓ stream events back as Linear comments
  ↓ on success: open PR, remove label
  ↓ on failure: post error, remove label

This is the Linear agent loop and the shell version of it. Most teams build the shell version first and graduate to a managed one.

What makes Background Claude different from just “using Claude in a script”

Four properties, in rough order of impact:

1. No human in the loop for approvals. This forces explicit permission-mode decisions. dontAsk is the only CI-safe mode — the others either block on approval or auto-accept dangerously.
2. Explicit cost caps. A confused Claude with no budget can run up a bill fast. --max-turns and --max-budget-usd are non-negotiable flags. See the pricing deep-dive for a budgeting formula.
3. Structured output. If no human is watching, a downstream system needs to be. That usually means --output-format stream-json so events can stream into a dashboard, a Linear comment, or a log.
4. Isolation. Two concurrent Background Claude runs on the same repo will fight. The fix is git worktree per run.

What Background Claude isn't

• Not a specific Anthropic product.Anthropic ships Claude Code. “Background Claude” is the category of usage pattern, not a SKU.
• Not a subscription tier. Every plan lets you run claude -p. Background usage is a pattern, not an entitlement.
• Not the same as Anthropic's hosted scheduler. Claude Code's native /loopcommand is one way to do Background Claude, but it's just one of several surfaces — and not the right one for event-triggered work.

Who uses Background Claude, and why

From what we've seen across engineering teams adopting it:

• Solo engineers wiring claude -p into pre-commit hooks, PR scripts, and nightly sweeps for their own repos.
• Small teams wiring Claude into GitHub Actions for auto PR review and documentation updates. See the GitHub Actions recipe.
• Product teams routing Linear issues through Claude for first-pass implementation. This is where the managed-agent pattern becomes essential — and where DIY loops start to fray.

Start here

• New to the concept? Read the About page for a plain-English primer.
• Want to ship one today? Start at the headless guide and the Linear CLI shell loop.
• Evaluating DIY vs managed? The /vs page has 14 honest rows.
• Just want the flags?Everything's in the CLI reference.

Takeaways

• Background Claude is the umbrella term for any Claude Code usage without a human pressing enter.
• Three levels: headless (one-shot), scheduled (recurring), and agent (event-triggered). Each builds on the previous.
• Four things make it different from scripting Claude: no human approvals, explicit cost caps, structured output, and per-run isolation.
• Start with headless, graduate to scheduled, graduate again to agents when the loop matters more than the individual run.