How to hand work to an agent that runs without you

You learned to use an agent by watching it. It proposed a command, you read it, you approved it, and the loop repeated until the work was done or you stopped it. Then you found the setting that lets the same agent keep working after you close the laptop, and the loop quietly disappeared. Claude Code sends the task to an isolated, Anthropic-managed virtual machine, and the session persists even if you close your browser [1]. Codex creates a container, checks out your repository at the selected branch or commit, and then the agent “runs terminal commands in a loop”, editing code and validating its work before it shows you a diff [4]. Cursor’s cloud agents “run in isolated VMs in the cloud with full development environments instead of on your local machine” [6].

The useful question is not whether that works. It works. The question is what you have agreed to, because every decision you used to make by reading a proposed command has moved somewhere else, and if you do not put it somewhere on purpose it ends up nowhere. This guide is for someone who already uses one of these agents interactively and is deciding whether to leave it running unattended. It is not a setup walkthrough, and it is not for teams running their own self-hosted agent infrastructure, which has a different set of controls and its own documentation.

An unattended agent is a process, not a conversation

The interactive model and the background model differ in one specific way, and vendors are direct about it. In a Claude Code cloud session started by hand you still pick a permission mode from the mode dropdown, both when you create the task and while the session runs [1]. Schedule that same work as a routine and the choice is gone. Anthropic’s documentation states it plainly: “Routines run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run” [3]. What the routine can reach is set by the repositories you select, the environment’s network access and variables, and the connectors you include [3].

That is the whole shift. In a conversation, your judgment arrives during the run. In a process, your judgment has to arrive before it, encoded in configuration, or after it, applied to a diff. There is no third option, and pretending there is one is how people end up surprised by an agent that did exactly what they configured.

Two consequences follow immediately. The prompt has to carry everything, because nobody is there to answer a clarifying question; Anthropic’s own guidance is that a routine’s prompt “must be self-contained and explicit about what to do and what success looks like” [3]. And the failure mode changes: a stalled interactive session is obvious because you are looking at it, while a background run that took a wrong branch two hours ago looks identical to a successful one until you open it.

The environment, not the prompt, is where the limits live

Both major vendors put the real controls in the sandbox configuration rather than in what you write. Claude Code cloud environments offer four network access levels: None allows no outbound connections through the session’s network, Trusted allows an allowlist of package registries, GitHub and cloud SDKs, Full allows any domain, and Custom takes your own list [2]. The Default environment onboarding creates uses Trusted [1]. Requests on that path to hosts outside the allowlist fail with 403 and x-deny-reason: host_not_allowed [3].

Codex draws the same line in a different place. Internet access is available during the setup script phase so dependencies can install, and then “Agent internet access is off by default” for the phase where the model is actually driving [4]. When you turn it on, the presets are an empty allowlist you add to, a preset list of common dependency domains, or unrestricted [5]. You can also restrict network requests to GET, HEAD and OPTIONS, so that requests using other methods are blocked [5].

Credentials get the same treatment. In Anthropic-hosted environments, git credentials and signing keys stay outside the sandbox and a proxy authenticates on the session’s behalf with scoped credentials [1]. On Pro and Max plans you can store an API key on the environment that the proxy attaches to matching requests after they leave the VM, so that “The key never reaches Claude, the commands it runs, or the session’s environment variables” [2]. Plain environment variables are the weaker option, because they are visible to anyone who uses the environment, which is exactly why Anthropic points you at stored credentials instead [3]. Codex splits environment variables from secrets, where secrets are stored with an additional layer of encryption and “are only available to setup scripts. For security reasons, secrets are removed before the agent phase starts” [4].

This is OWASP’s privilege-control mitigation implemented at the platform level: restrict the model’s access privileges to the minimum necessary for its intended operations, and give the application its own API tokens for extensible functionality, handling those functions in code rather than providing them to the model [8]. Your job is to not undo it. The temptation with a background agent is to widen network access to Full and paste every key into environment variables so the run does not fail at 3am. That converts a contained process into an uncontained one, and you will not be watching.

Assume the agent will read something a stranger wrote

OWASP defines prompt injection as user prompts altering a model’s behaviour or output in unintended ways, and describes indirect prompt injection as what happens when a model accepts input from external sources such as websites or files, where data in that external content can alter the model’s behaviour in unintended or unexpected ways [8]. An agent that reads issues, fetches a dependency’s README, or opens a web page during a run is processing text that someone else wrote.

Codex’s documentation lists what that costs when it goes wrong: prompt injection from untrusted web content, exfiltration of code or secrets, downloading malware, and pulling in content with license restrictions. Its guidance is one sentence long: “Point Codex only to trusted resources and keep internet access as limited as possible” [5].

Anthropic applies the same reasoning to input, not just output. When you trigger a routine over its API endpoint, the optional text you pass does not arrive as a bare message. It is wrapped in a <routine-fire-payload> block that labels it as untrusted data and tells Claude not to follow instructions inside it unless the routine’s own prompt says to [3]. The routine’s prompt has to opt in explicitly, with wording like “Investigate the alert described in the routine-fire-payload block”, or the routine treats the text as inert context [3]. The reasoning is stated: anyone holding the bearer token can send that text, so the wrapper makes fire text from a leaked token arrive labelled as untrusted data rather than as direct instructions [3].

None of this is airtight, and Anthropic says so. Even with network access disabled, “Claude Code can still communicate with the Anthropic API, which may allow data to exit the VM” [1]. Treat the network level as a large reduction in exposure, not a guarantee.

Your approval moves to the two ends of the run

If you cannot approve during, you approve before and after. Before means the prompt and the plan. Anthropic’s own suggested pattern for complex work is to start locally in plan mode, where Claude reads files and proposes an approach without editing source code, then save the plan to the repo, commit and push it, and start a cloud session that executes it [1]. You are approving a written plan instead of 40 individual tool calls, which is a worse instrument for catching small mistakes and a better one for catching wrong direction.

After means the diff, and it means actually opening it. Each session shows a diff indicator with lines added and removed, and selecting it opens a diff view where you can leave inline comments on specific lines and send them to Claude with your next message [1]. The trap is the run list, and Anthropic flags it directly: “A green status in the run list means the session started and exited without an infrastructure error. It does not mean the task in your prompt succeeded” [3]. Blocked network requests, missing connector tools and task-level failures all surface in the transcript rather than in the status indicator [3].

One more thing to check after: what was still running when the machine went away. Cloud sessions stop after a period of inactivity and the session’s VM is reclaimed, and reopening the session provisions a fresh VM with the conversation history restored, but background work that was still running, such as subagents and shell commands, is not restored [1].

The agent acts as you, and that reaches past the repository

The identity question is the one operators underestimate. Anthropic is explicit that routines belong to your individual claude.ai account and that “Anything a routine does through your connected GitHub identity or connectors appears as you: commits and pull requests carry your GitHub user, and Slack messages, Linear tickets, or other connector actions use your linked accounts for those services” [3]. When you create a routine, all of your currently connected connectors are included by default, and Claude “can use every tool from an included connector, including writes, without asking for permission during a run” [3]. Removing the ones the job does not need is the highest-value configuration step on the page.

The reach can be longer than it looks. With auto-fix enabled on a pull request, Claude may reply to review comment threads using your GitHub account, so replies appear under your username, each one labelled as coming from Claude Code [1]. Anthropic attaches a warning to that: if your repository uses comment-triggered automation such as Atlantis, Terraform Cloud, or custom GitHub Actions that run on issue_comment events, Claude can reply on your behalf and trigger those workflows, and you should consider disabling auto-fix for repositories where a PR comment can deploy infrastructure or run privileged operations [1].

There are guardrails on the write path. Claude pushes work to branches prefixed with claude/, which are always accepted, and a push to any other branch is rejected if the branch is protected on GitHub, if someone else has an open pull request from it, or if it carries commits authored by someone other than you [3]. Cursor’s requirement is blunter: “You need read-write privileges to your repo and any dependent repos or submodules” [6].

Sharing defaults deserve one look before you send anyone a link. On Enterprise and Team accounts, the visibility options are Private and Team, and repository access verification is enabled by default [1]. On Max and Pro accounts the options are Private and Public, where public means visible to any user logged into claude.ai, and repository access verification is not enabled by default [1]. Sessions may contain code and credentials from private GitHub repositories [1].

What you pay is rate limit, not a compute bill

The pricing model surprises people in a good way and then in a bad way. Claude Code on the web shares rate limits with all other Claude and Claude Code usage within your account, running multiple tasks in parallel consumes more rate limits proportionately, and “There is no separate compute charge for the cloud VM” [1]. Routines draw down subscription usage the same way interactive sessions do, with an additional daily cap on how many runs can start per account; without usage credits turned on, additional runs are rejected until the window resets [3]. The minimum schedule interval is 1 hour, and expressions that run more frequently are rejected [3]. Cursor takes the other approach: cloud agents “are charged at API pricing for the selected model” [6].

So the constraint on Claude is your plan. Pro is $20 per month, or $17 per month on an annual subscription; Max starts from $100 per month; a Team standard seat is $25 per month, or $20 per seat per month billed annually, and a Team premium seat is $125 per month, or $100 per seat per month billed annually [7]. Claude Code on the web is in research preview for Pro, Max and Team users, and for Enterprise users with premium seats or Chat plus Claude Code seats [1]. Routines are available on Pro, Max, Team and Enterprise plans [3].

The machine you get is ordinary, and worth knowing before you schedule a large build. Anthropic-hosted sessions run with approximate ceilings of 4 vCPUs, 16 GB of RAM and 30 GB of disk, and the VM may stop tasks that need significantly more memory, such as large build jobs or memory-intensive tests [2]. Startup is fast because the setup script runs once and Anthropic snapshots the filesystem and reuses that snapshot, with the script re-running when you change it or the environment’s allowed network hosts, and when the cache reaches its expiry after roughly seven days [2]. Codex caches container state for up to 12 hours to speed up later chats, and invalidates that cache when you change the setup script, maintenance script, environment variables or secrets [4]. The Anthropic cache is a filesystem snapshot, so it keeps what the setup script writes to disk and loses anything that was only running: a database the script started is not there next time [2].

What still goes wrong

The honest failure is attention, not security. Six unattended runs waiting for review on Monday morning is not six tasks done; it is six diffs and six transcripts to read, and the green status tells you only that the session started and exited without an infrastructure error [3]. If you would not have read the output when you asked for it interactively, scheduling it does not make that reading optional. Run the numbers in the calculator above against the hours you actually have before you add the fifth routine.

The second is that this is young software. Anthropic labels Claude Code on the web a research preview, and says of routines that behaviour, limits and the API surface may change [1][3]. The /fire endpoint ships behind a dated beta header, with breaking changes shipping behind new dated header versions [3]. Do not build a business process on any of it without a manual fallback you have actually tested.

The third is that several common setups simply cannot use it. Organisations with Zero Data Retention enabled cannot use cloud session features [1]. If your organisation has IP allowlisting enabled, every Anthropic-hosted cloud session fails with an authentication error, because those sessions call the Anthropic API from Anthropic-managed infrastructure rather than your network [1]. Repository cloning and pull request creation require GitHub; GitLab, Bitbucket and other non-GitHub repositories can be sent to a cloud session as a local bundle, which must be under 100 MB, but the session cannot push results back to the remote [1]. And prompt injection is reduced by these controls rather than solved by them, which is why OWASP’s standing advice is still to implement human-in-the-loop controls for privileged operations, and why it says it is unclear whether any fool-proof method of prevention exists [8]. The background execution model asks you to decide in advance which of your operations are privileged. That decision is the work.