Guides · September 2026
Background agents, defined
What the term means, the seven products that mean slightly different things by it, what an agent needs to work while you are gone, and whose machine it is on.
The definition.
A background agent is an agent handed a task that it carries out unattended — in its own environment, on its own clock — and that reports back when it is done, interrupting you only when it must. The contrast is the foreground agent, the one you sit with: you send a message, it works, you read the result, you send the next. A background agent removes the turn-taking. You dispatch, you leave, and the next thing you see is a branch, a pull request, a diff, or a question.
Four properties make one. It runs unattended, which takes the judgment to keep going when the plan meets reality. It runs in a real environment — a checkout, a toolchain, a way to run the tests — because an agent that cannot execute is a draft generator. It has a return path, so the work arrives somewhere you will look. And it has an interrupt: a way to ask for a permission or a decision without losing its place. Those four separate it from a scheduled job (no judgment), a subagent (spawned by another agent, inside its process), and a chatbot with a long timeout.
The products that use the term.
Seven products, checked against their own documentation. Count how many mean ‘a fresh machine of ours per task’, and note the one that does not.
| Product | What it actually is | Where it runs | How it comes back |
|---|---|---|---|
| Cursor cloud agents | Formerly Background Agents: the Cursor agent in a remote VM with the repo cloned and dependencies installed | Isolated Ubuntu VMs in Cursor’s cloud, charged at API pricing for the model | A branch pushed to your repo, then a PR; started from the desktop app, cursor.com/agents, Slack, the iOS app, or an @cursor comment on GitHub or Bitbucket |
| Codex cloud | OpenAI’s Codex running delegated tasks, several in parallel | Isolated cloud environments configured per repository; GitHub or GitLab | A summary and diff to review, a PR when you ask; started from chatgpt.com/codex, the app, the CLI, GitHub, GitLab, Linear, or Slack |
| Claude Code on the web | Claude Code on Anthropic-managed infrastructure; research preview for Pro, Max, and Team | An isolated VM per session, reclaimed after inactivity; no compute charge, shared rate limits | A PR from the web, or claude --teleport to pull the session into your terminal; started at claude.ai/code, the mobile app, or claude --cloud |
| Claude Code Remote Control | The reverse: a session on your own machine, driven from the Claude app or claude.ai/code | Your machine; if the laptop sleeps it reconnects when the machine is back, and nothing ran in between | The session itself, live on your phone; the transcript sits on Anthropic’s servers to keep devices in sync |
| Copilot cloud agent | GitHub’s agent, formerly Copilot coding agent; assign it an issue or mention @copilot | An ephemeral GitHub Actions environment; paid Copilot plans, using Actions minutes and AI credits | Changes on a branch, a draft PR when you want one |
| Google Jules | Google’s autonomous coding agent; it plans before it edits | A VM where it clones the repo and installs dependencies; free tier of 15 tasks a day, 3 at once | A plan to approve, then a PR; a notification when it finishes or needs you |
| Devin | An autonomous AI software engineer that writes, runs, and tests code | Its own cloud environment; reached from app.devin.ai, Slack, Teams, or a CLI | A PR at the end of a session |
What a background agent needs.
A real environment
The repo with its dependencies, its test suite, its .env, its GPU if the work needs one. Hosted products rebuild this per task from a definition; your own machine already has it.
Persistence
The agent must outlive the device that dispatched it. A closed laptop cannot end the run, and a two-hour job cannot depend on a browser tab.
A way to reach you
Permission prompts and questions are the point of the interrupt. If they land in a terminal nobody is watching, the agent waits — sometimes all night.
A way back
A branch and a PR is the common answer. Better is that plus the ability to step into the session and take over when the PR is wrong in a way a comment cannot fix.
Hosted, or your own machine.
Every product in the table sits on one side of a line. The hosted ones — Cursor, Codex, Claude Code on the web, Copilot, Jules, Devin — give you a fresh machine per task, parallelism up to your plan’s limits, and none of the operations. They also give you their constraints: the repository must be somewhere they can clone, mostly GitHub; the secrets and services a task needs must be reproducible from a config; the environment is theirs to reclaim when the task goes quiet, as Claude Code on the web does with an idle VM; and the machine is theirs, which matters when the work involves a private dataset, a model on your own GPU, or code that is not allowed to leave the building. The rate limits and the meter are theirs too.
The other side is your own hardware, where nothing is rebuilt because the environment already exists. Remote Control is the instructive case: Anthropic’s own answer to ‘drive my machine from my phone’, and it is exactly that — the session runs on your laptop, and when the laptop sleeps the agent stops until it wakes. That is the gap. A background agent on a machine you own needs the machine to stay up, the session to survive whatever you do with the screen, and a channel to you that does not depend on a terminal being watched.
Where spawnd sits.
spawnd is that substrate, not another agent. One daemon on each host you own dials out, so nothing listens and no port opens. Every session lives on the host, its PTY owned by a worker process, so an agent dispatched at six is still running at nine whichever laptop lid closed in between, and it comes back with scrollback intact even after the daemon restarts. Workspaces, one per project, hold a grid of those sessions across hosts; when an agent stops to ask for a yes, the session shows an attention cue and your phone gets a notification, and any browser is the console to answer from — no client app, no keys on the device. The agents are the ones you already run: Claude Code, Codex, OpenCode, and Aider as built-in shortcuts, any other CLI as a named command, each signing in on the host as it always has. What spawnd does not do is decide what the agents work on — that is orchestration, and it sits above this. What it does is make keeping agents running, and running several at once, a property of the host rather than a habit of yours.
Start
Give your agents a machine that stays on.
curl -fsSL https://spawnd.dev/install.sh | shQuestions
- Is a background agent the same as an autonomous agent?
- Autonomy is the capability — choosing its own steps. Background is the arrangement — running unattended in its own environment and reporting back. Every background agent is autonomous; a foreground session of the same agent is not background.
- Do background agents need GitHub?
- The hosted ones mostly do: they clone from it and return pull requests to it, with GitLab or Bitbucket supported by some. An agent on your own machine works in whatever checkout is there, GitHub or not.
- Can Claude Code be a background agent on my own machine?
- Yes, two ways. Remote Control keeps the session local and lets your phone drive it, but the run stops when the machine sleeps. Under spawnd the session lives on a host that stays on, and the phone is one of several consoles to it.