Category: Remote Workflows

There are six ways to make Claude Code do something when you are not sitting at the terminal, and they are easy to confuse because several share the same claude.ai interface. This is the whole family in one place, sorted by the only question that actually decides between them.

Narrow it down

Four questions, one recommendation, and an honest note about what you give up by taking it. If your answers turn out to be incompatible, which happens more often than you would think, it says so rather than picking something that cannot work.

The whole family

Method	What starts the work	Code runs on	Plans
Remote Control	You drive a running session from claude.ai or the app	Your machine	Pro, Max, Team, Enterprise
Dispatch	You message a task from the Claude mobile app	Your machine, via Desktop	Pro and Max only
Channels	An external event is pushed in: CI, a webhook, a chat message	Your machine	Pro, Max; Team and Enterprise need an admin toggle
Claude in Slack	Someone mentions @Claude in a channel	Anthropic cloud	Pro, Max, Team, Enterprise
Claude Code on the web	You start a task in the browser or with --cloud	Anthropic cloud	Pro, Max, Team, Enterprise premium
Scheduled tasks	A schedule you set	CLI, Desktop, or cloud	All

Note the plan column, because it contains the most counter-intuitive fact here. Dispatch is the only one restricted to individual plans. It is unavailable on Team and Enterprise, which is the exact inverse of how these restrictions usually run.

Decide in two questions

Will your machine be on and awake?

If no, your options collapse to two: Claude Code on the web, or a cloud scheduled task. Everything else drives a process on your own hardware and dies with it. Remote Control, Dispatch and channels all need the machine up, and Remote Control additionally times out after roughly ten minutes without network.

If yes, keep going.

Does the work need your actual files?

If it needs your local filesystem, your MCP servers, your uncommitted changes or your project config, then it has to run locally: Remote Control, Dispatch or channels. A cloud session clones from GitHub and cannot see anything you have not pushed, let alone reach a database on your laptop.

If it does not, the cloud options are less hassle. No machine to keep awake, no timeout, and the session survives you closing the lid.

Supervising against delegating

The three local options differ in who decides what happens, and that is the distinction people miss when they pick one.

• Remote Control is supervision. You open the session, you steer it, the phone is a window onto work already underway. Best when you want to watch and interject.
• Dispatch is delegation. You message a task and Dispatch decides how to handle it, spawning a Code session in Desktop when the work looks like development. Bug fixes, dependency updates and test runs typically route to Code; research and document work stay in Cowork. The session appears with a Dispatch badge and pushes you a notification when it finishes or needs approval.
• Channels are reaction. Nothing starts until something outside happens, and then the event lands in a session you already have open. A CI failure arrives where Claude still has your files loaded and remembers what you were debugging.

They compose. Start work through Dispatch, then attach Remote Control to the resulting session and follow it in detail from your phone.

What Slack actually is, and what is replacing it

Of all six, Slack is furthest from Remote Control. An @Claude mention does not touch your machine at all: it creates a cloud session working from a GitHub clone. It works in public and private channels only, never in direct messages, and Claude has to be invited to a channel before it will answer there:

/invite @Claude

That invite requirement is more useful than it looks, because channel membership becomes your access control. Admins gate who can use Claude Code by managing which channels it lives in.

Two details worth knowing before you roll it out. Sessions run under each individual’s own account and rate limits, and they can only reach repositories that person personally connected. And on Team and Enterprise, sessions created from Slack are automatically visible to the whole organisation rather than private.

The error that generates the most confusion is Claude Code is not enabled for your account. It sounds like an admin block. It is not: it means that account has no cloud environment yet. Signing in once at claude.ai/code creates it and the error clears. Every user has to do this individually, which is why it arrives as a wave of complaints just after rollout.

Reaching all of this from your phone

There is no separate Claude Code app. The Claude app for iOS and Android is a client, and the Code tab reaches cloud sessions and Remote Control alike, while Dispatch is a task you message. To get the app quickly, run /mobile in any session and scan the QR code it displays. /ios and /android do the same.

The limitation that catches people out is permission modes, and it differs by session type:

Session type	Offered in the app	Not available
Cloud session	Accept edits, Plan, Auto	Bypass permissions
Remote Control	Manual, Accept edits, Plan	Bypass permissions, and Auto

So the mode you would most want for a long unattended remote session cannot be selected from the phone at all. Set it on the host before you leave. Full detail in permission modes, and the phone-specific behaviour in Remote Control on iPhone and Android.

The short version

• Machine off: Claude Code on the web, or a cloud scheduled task.
• Machine on, needs local files, you want to watch: Remote Control.
• Machine on, needs local files, you want to delegate: Dispatch, if you are on Pro or Max.
• Machine on, reacting to an external event: channels.
• Starting work from team conversation: Slack, or Claude Tag if you are on Team or Enterprise.

From 14 August 2026, auto mode is the default permission mode for new Claude Code sessions on Pro, Max and Team plans. If Claude suddenly stops asking before it runs commands, nothing is broken. The default changed underneath you.

Exactly what changes

Situation	What happens on 14 August
You never set a default mode	New sessions start in auto mode instead of Manual
You set a default yourself	Your setting stays. You get a one-time prompt offering the switch, which you can decline
Your organisation manages the default	Nothing changes
You are on Enterprise	Not included in this change

Existing sessions are not converted mid-flight, and you can still switch modes at any time with Shift+Tab or the mode selector. This changes the starting point, not your control over it.

One change already in effect on those plans, and easy to miss: the classifier calls auto mode makes no longer count toward your usage limits. That removes the main practical argument against leaving it on.

What auto mode actually does

It is not “approve everything”. A separate classifier model reviews each action before it runs and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognise, or looks driven by content Claude just read rather than by you.

Blocked by default, among a long list: curl | bash, production deploys and migrations, force push, git reset --hard, terraform destroy, mass deletion on cloud storage, printing a live credential into the transcript, and opening a tunnel that exposes a local service to the internet.

Allowed by default: local file operations in your working directory, installing dependencies your lock files already declare, read-only HTTP requests, and pushing to branches of the repository you are working in.

Keeping Manual, or choosing something else

The mode that reviews every action is labelled Manual but its config value is default. From v2.1.200 the CLI also accepts manual as an alias, so either works:

{
  "permissions": {
    "defaultMode": "manual"
  }
}

Put that in ~/.claude/settings.json for every project. Other values are acceptEdits, plan, auto, dontAsk and bypassPermissions, described in permission modes.

To go the other way and start every session in auto mode now, before the switch:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

New sessions then show auto mode on in the status bar.

If you administer a team

Administrators can remove auto mode entirely by setting permissions.disableAutoMode to "disable" in managed settings. That takes it out of the Shift+Tab cycle and rejects --permission-mode auto at startup.

Worth deciding deliberately rather than by default. Auto mode reduces prompt fatigue substantially, and the classifier blocks a long list of genuinely destructive actions, but Anthropic is explicit that it reduces prompts rather than guaranteeing safety.

Why this matters more for remote sessions

Permission mode is the single thing that decides whether a session you are not watching finishes or stalls. A Remote Control session, a channel waiting on a CI event, or a background session all stop dead at a permission prompt until someone answers it.

So for anyone driving Claude Code from a phone or leaving work running, this change is an improvement rather than an intrusion. It is the difference between coming back to finished work and coming back to a question from twenty minutes ago.

Two caveats specific to remote work:

• You cannot select auto mode from the phone for a Remote Control session. The app offers Manual, Accept edits and Plan only. Set it on the host before you leave.
• Auto mode still pauses eventually. If the classifier blocks three actions in a row, or twenty in a session, it stops and reverts to prompting. Those thresholds are not configurable, so auto mode lowers the odds of a stall without eliminating them.

What to do today

1. Decide whether you want auto mode. For most people driving sessions remotely, yes.
2. If you want to keep Manual, set defaultMode in ~/.claude/settings.json before the 14th, or decline the one-time prompt when it appears.
3. If you administer a team, decide whether disableAutoMode belongs in your managed settings rather than discovering the change through a support ticket.
4. Either way, read what the classifier blocks and allows once, so the first block does not look like a bug.

Your Claude Code sessions can message each other. On one machine that happens over a local socket. Across machines it travels over the Remote Control connection, which makes this the one feature where Remote Control is doing work you never asked it to do.

What a message actually is

A piece of plain text one Claude writes to another. Never conversation history, never files. The receiving session gets the sender name, the text, and usually a reply address, and nothing else. To move a whole conversation somewhere, resume the session instead.

Claude uses two tools, ListAgents to see what it can reach and SendMessage to deliver, so you never call either yourself. You just say what you want the other session to know:

Ask the session running in my other terminal whether the migration finished

Claude writes the message itself. What arrives looks like a sentence a colleague would send: Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

Where the other session is decides what you can do

Other session runs	How it travels	What you can send
On this machine	A per-session socket, never through Anthropic servers	New messages and replies
On another of your machines	Through Anthropic servers, arriving over that machine’s Remote Control connection	Replies only
On Claude Code on the web	Through Anthropic servers to the cloud session	Replies only

That reply-only restriction is the important asymmetry. Claude cannot start a conversation with a session on another machine. It can only answer one that arrived. So the cross-machine channel opens from the far side, and Remote Control is what holds it open.

Why a session you expect is missing from the list

Same-machine discovery works through files on disk. Each session registers itself and binds an inbox socket there, and sessions can only reach each other when they can see the same files.

So a session inside a container and a session on the host cannot message each other, because the container has its own filesystem. Two sessions inside the same container still can.

Sessions answer to the name set with /rename or --name. Without one, Claude Code derives a name from the working directory folder, such as myapp-3f. Two sessions can end up with the same name, which is why /list-agents shows working directories.

What an incoming message is not allowed to do

Claude Code tells the receiving session the message came from another session, not from you, and constrains it accordingly:

• It cannot approve anything. A message never counts as your consent, so it cannot answer a pending permission prompt.
• It cannot change configuration. Claude is instructed never to alter permission settings or CLAUDE.md because another session asked.
• Commands do not run. A /compact in the text arrives as text.
• Permission prompts still fire for anything acting on the message requires.

Claude is also instructed never to ask another session to do something that was denied in its own session, and to route that back to you instead.

Controlling what arrives

Set crossSessionInbound to decide what a session does with messages from your other sessions:

Value	Behaviour
accept	Every message is delivered
hold	A notice appears, nothing is delivered until you approve
refuse	Messages are dropped silently

With no value set, Claude Code decides per message from the two sessions’ permission modes. Sessions that bypass permission prompts form one class, everything else the other. A session that prompts for permissions accepts messages, except from a bypassing sender. A session that bypasses holds everything unless the sender also bypasses.

A held message opens an approval dialog showing sender and preview. Leave it and it expires after dialogExpiry, five minutes by default, and the message is dropped. Claude Code holds at most 100 messages and drops the oldest past that.

Keeping messages on one machine

If you would rather nothing left the machine without you saying so:

{
  "isolatePeerMachines": true
}

That requires your explicit approval before any SendMessage reaches a session beyond this machine, and it holds even in bypassPermissions mode. A true from any settings scope applies, so a checked-in project file can turn it on but not off. Same-machine messages never prompt.

To switch the feature off completely, both directions need handling:

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

Note that denying SendMessage also removes messaging to subagents and agent-team teammates, since one tool serves all three.

Headless workers

A claude -p session binds an inbox socket like an interactive one, so a long-running worker can receive messages and shows in the listing. Bare mode does not bind one.

The catch: a -p session cannot show an approval dialog, so a held message stays held forever. To let an unattended worker take messages, start it with crossSessionInbound set to accept in its --settings value.

Loops cannot run away

Two sessions messaging each other in circles is the obvious failure mode, and it is handled. Claude Code rate-limits repeated messages per sender, drops identical repeats arriving in a short window, and caps accepted messages waiting to be read at 50 per session. A loop therefore stops on its own.

Related: background sessions for the parallel sessions you would message, worktrees for keeping their edits apart, and permission modes for the two classes the inbound default uses.

Most ways of keeping Claude working need you to prompt each step, which defeats the point when you are away from the keyboard. /goal sets a completion condition instead. After every turn a small fast model checks whether the condition holds, and if it does not, Claude starts another turn rather than handing control back to you.

Three ways to keep a session going, and how they differ

Approach	Next turn starts when	Stops when
/goal	The previous turn finishes	A model confirms your condition is met
/loop	A time interval elapses	You stop it, or Claude decides the work is done
Stop hook	The previous turn finishes	Your own script or prompt decides

/goal is the session-scoped shortcut: you type a condition and it applies to this session only. A Stop hook lives in your settings, applies to every session in scope, and can run a real script for deterministic checks.

Auto mode is a different axis entirely. It approves tool calls within a turn but never starts a new one. The two compose well: auto mode removes per-tool prompts, /goal removes per-turn prompts. On its own, /goal does not change permissions at all, so in the default mode Claude will still stop and ask before running your test command. For genuinely unattended work you need both.

Setting one

/goal all tests in test/auth pass and the lint step is clean

That starts a turn immediately, using the condition itself as the directive. No separate prompt needed. A ◎ /goal active indicator shows how long it has been running. One goal per session, and setting a new one replaces the old.

Writing a condition that actually works

This is where people get it wrong, and the reason is specific: the evaluator does not run commands or read files. It judges your condition against what Claude has already surfaced in the conversation. So the condition has to be something Claude’s own output can demonstrate.

“All tests in test/auth pass” works, because Claude runs the tests and the result lands in the transcript where the evaluator can read it. “The code is well structured” does not, because nothing in the transcript proves it.

A durable condition usually has three parts:

• One measurable end state: a test result, a build exit code, a file count, an empty queue.
• A stated check: how Claude should prove it, such as “npm test exits 0″ or “git status is clean”.
• Constraints that matter: anything that must not change on the way, such as “no other test file is modified”.

Conditions can run to 4,000 characters. To bound how long it goes, put the limit in the condition itself: or stop after 20 turns. Claude reports progress against that clause each turn and the evaluator judges it from the conversation.

Checking and clearing

/goal with no argument shows the condition, how long it has run, turns evaluated, token spend, and the evaluator’s most recent reason. That reason is the useful part, because it tells you what Claude is aiming at next.

/goal
/goal clear

stop, off, reset, none and cancel all work as aliases for clear. Running /clear to start a fresh conversation also removes an active goal.

A goal still active when a session ends is restored on --resume or --continue. The condition carries over, but the turn count, timer and token baseline all reset.

Running it headless

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

What is happening underneath

/goal is a wrapper around a session-scoped prompt-based Stop hook. After each turn, Claude Code sends the condition and the conversation to your configured small fast model, which defaults to Haiku on the Claude API. The model answers yes or no with a short reason. On no, Claude keeps working and treats the reason as guidance. On yes, the goal clears and an achieved entry is recorded.

Evaluation tokens are billed on that small model and are usually negligible next to the main turns.

When it will refuse to run

Because the evaluator is part of the hooks system, /goal needs an accepted workspace trust dialog. It is also unavailable when disableAllHooks is set at any settings level, or when allowManagedHooksOnly is set in managed settings. In each case the command explains why rather than failing quietly.

Pairing it for remote work

The combination that works when you are not at the desk: set the permission mode on the host before you leave, start the session with Remote Control, then set a goal with a bounded condition. Auto mode handles the tool calls, the goal handles the turns, and you check in from your phone to read the evaluator’s reasoning rather than to type prompts.

See permission modes for the half that stops prompts, and scheduled tasks for interval-based work instead.

Remote Control’s server mode accepts --sandbox, and it is off by default. If you are leaving a session running on a machine you are not watching, that default deserves a decision rather than a shrug. Here is what turning it on actually changes.

Platform support first

On macOS there is nothing to install, because the sandbox uses the built-in Seatbelt framework. On Linux and WSL2 it needs two packages:

• bubblewrap, the unprivileged sandboxing tool that enforces filesystem isolation
• socat, the relay that routes network traffic through the sandbox proxy

Native Windows is not supported. Run Claude Code inside a WSL2 distribution instead.

The two modes

Mode	Behaviour
Auto-allow	A command that can be sandboxed runs inside it and is approved automatically, with no prompt
Regular permissions	Every Bash command goes through the normal permission flow even when sandboxed

Both enforce identical filesystem and network restrictions. The only difference is whether sandboxed commands need approval. For a session you are not watching, auto-allow is the point of the exercise.

Even in auto-allow, these still interrupt:

• Explicit deny rules, always.
• rm or rmdir targeting /, your home directory, or other critical system paths.
• Content-scoped ask rules such as Bash(git push *).

What the sandbox actually restricts

Filesystem

• Writes: the working directory, its subdirectories, and the session temp directory that $TMPDIR points to. Nothing else, including ~/.bashrc and system binaries.
• Reads: the entire computer, minus a denied set.

One useful special case: when the working directory is a linked git worktree, the sandbox permits writes to the main repository’s shared .git directory so git commit still works. Writes to hooks/ and config inside it stay denied.

Network

Traffic goes through a proxy running outside the sandbox, and no domains are pre-allowed. The first time a command needs a new domain, Claude Code asks. Approving allows that host for the rest of the session.

For unattended work this is the thing that will bite you. A prompt for a domain is still a prompt, and a session nobody is watching stops at it. Pre-allow what your build actually needs:

{
  "sandbox": {
    "allowedDomains": ["registry.npmjs.org", "github.com"]
  }
}

The escape hatch, and why it exists

Some commands simply cannot run sandboxed. Rather than failing the task, Claude analyses the failure and may retry with the dangerouslyDisableSandbox parameter. That retry runs outside the sandbox and goes through the normal permission flow, so you get a confirmation prompt in default mode, or a classifier check in auto mode.

If you would rather that never happen quietly, turn it off:

{
  "sandbox": {
    "allowUnsandboxedCommands": false
  }
}

Or keep it but force a prompt every time by adding an ask rule for Bash(dangerouslyDisableSandbox:true).

Turning it on properly

Selecting a mode in the /sandbox panel saves it to .claude/settings.local.json, which applies to that project only. Claude Code adds that file to your global gitignore when it does. For every project, set it in your user settings:

{
  "sandbox": {
    "enabled": true
  }
}

Organisations can enforce it for everyone through managed settings.

Using it with Remote Control

Server mode takes the flag directly:

claude remote-control --sandbox --spawn worktree

Two caveats worth holding onto. The flag is not available with the /remote-control slash command, only with server mode, so a session you converted mid-flight cannot pick it up. And sandboxing is not a substitute for permission mode: they solve different problems, and a sandboxed command can still be one you would rather approve.

For a machine that stays on and hosts sessions you are not watching, the combination worth reaching for is sandbox enabled, domains pre-allowed, and a permission mode chosen deliberately. See always-on machines and the security model.

Remote Control’s server mode takes --spawn worktree, and background sessions use worktrees by default. Both lean on the same git feature, and if you do not know how it behaves you will eventually delete work you wanted. This is what is actually happening underneath.

Starting one

claude --worktree feature-auth
claude -w feature-auth

That creates .claude/worktrees/feature-auth/ at your repository root, on a new branch called worktree-feature-auth. Run it again with a different name in another terminal for a second isolated session. Omit the name and Claude generates one such as bright-running-fox.

Two things to do once, before this gets annoying:

• Add .claude/worktrees/ to your .gitignore, or every worktree shows up as untracked files in your main checkout.
• Run claude in the directory once to accept the workspace trust dialog. Interactive --worktree runs require it and exit with an error otherwise. Non-interactive -p runs skip the check.

The .env problem, and its fix

A worktree is a fresh checkout, so gitignored files are simply not there. Your .env is missing and nothing works. This catches everyone once.

Add a .worktreeinclude file at your project root, using gitignore syntax:

.env
.env.local
config/secrets.json

Those get copied into every worktree Claude Code creates with git, including subagent worktrees and Desktop parallel sessions. Only files that match a pattern and are gitignored are copied, so tracked files are never duplicated.

What happens when you exit

On exiting an interactive worktree session, Claude checks for changed files, untracked files, and new commits, then behaves differently depending on what it finds:

State	What happens
Clean, unnamed session	Worktree and branch removed automatically
Clean, named session	You are prompted first, so you can keep it
Has work in it	You are prompted to keep or remove. Removing deletes the directory, the branch, and the work

Isolation is enforced, not just suggested

While a session is in a worktree, Claude Code actively blocks attempts to reach the main checkout, and the same enforcement covers every subagent spawned from it:

• File edits targeting a path in the main checkout are blocked.
• Commands whose working directory resolves to the main checkout are blocked, including ones it cannot verify stay outside.
• Git redirects are blocked, whether through git -C, --git-dir, a GIT_DIR or GIT_WORK_TREE variable, or a cd into the main checkout before running git.

Claude sees each refusal as a tool error naming the worktree, so it can adjust rather than silently failing.

Where new worktrees branch from

By default they branch from the repository’s default branch on the remote, not from your current work. That surprises people who expected their in-progress feature branch to carry over. Change it with worktree.baseRef:

{
  "worktree": {
    "baseRef": "head"
  }
}

"fresh" is the default and starts from the remote default branch. "head" branches from your current local HEAD, carrying unpushed commits and feature-branch state. Use "head" when isolating subagents that need to work on what you are currently building.

You cannot set baseRef to a branch name. To start from a specific branch, create the worktree with git directly. You can, however, branch from a pull request:

claude --worktree "#1234"

Quote it so your shell does not read # as a comment. It fetches pull/1234/head and creates the worktree at .claude/worktrees/pr-1234.

Subagents in their own worktrees

Ask Claude to “use worktrees for your agents”, or make it permanent for a custom subagent with frontmatter:

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---

Each gets a temporary worktree, removed automatically when the subagent finishes with no changes. One with changes stays on disk until a periodic sweep can remove it without losing work.

The cleanup sweep

A periodic sweep removes worktrees Claude created for subagents and background sessions once they are older than your cleanupPeriodDays setting. It deliberately skips any worktree holding changed files, untracked files, or unpushed commits, and it never touches worktrees you made with --worktree.

While an agent runs, Claude locks its worktree with git worktree lock so concurrent cleanup cannot remove it. The sweep also releases locks left by sessions whose process died, so a killed background session no longer strands its worktree. Locks you set yourself are never released.

To remove one the sweep is keeping, use git worktree remove, adding --force if it has uncommitted changes.

What worktrees share with your main checkout

• The .git directory. Git commands in a worktree write to the shared repository, which is why git commit works from inside one even with sandboxing on.
• Project-scope plugins, so you do not reinstall per worktree. Requires v2.1.200 or later.
• Permission approvals. Choosing “don’t ask again” in a worktree saves to the main checkout’s .claude/settings.local.json, so it applies everywhere and survives the worktree being removed. Before v2.1.211 the approval was saved inside the worktree and lost with it.

Where this meets Remote Control

In server mode, --spawn worktree gives each on-demand session its own worktree instead of sharing one working directory. That is the setting that makes hosting several concurrent sessions actually safe:

claude remote-control --spawn worktree --capacity 6

The default, same-dir, shares one directory and will conflict when two sessions edit the same file. More on running several at once in sessions, and on leaving them running in background sessions.

Remote Control needs the session to stay running, which is why closing your terminal ends it. Background sessions sidestep that. They run under a supervisor process on your machine and keep going after you close agent view or the terminal entirely, which makes them the closest thing Claude Code has to leaving work running locally.

What agent view shows

Sessions grouped by state, with a one-line summary of each generated from its output. The icon tells you the state at a glance:

Icon	State	Meaning
Animated ✵	Working	Running tools or generating
Yellow ✻	Needs input	Waiting on a permission, answer, or question
Dimmed ∙	Idle	Ready for the next prompt
Green ✓	Completed	Finished successfully
Red ✗	Failed	Ended with an error
✢	Sleeping	A /loop session between iterations

The shape carries information too. A round dot means the process has exited but the session can still reply, restarting from saved state. That distinction matters when you are deciding whether something is stuck or simply idle.

Three ways to background something

From the shell

claude --bg "investigate the flaky auth test"
claude --bg --name "auth-fix" "task"
claude --bg --agent code-reviewer "review PR 412"
claude --bg --exec 'pytest -x'

From inside a session

/bg backgrounds the session you are in, optionally with a new instruction. /background is an alias. Pressing the left arrow on an empty prompt does the same thing and opens agent view. From v2.1.212, /fork copies the conversation into a new session instead of moving it.

From agent view

Type a prompt and press Enter to dispatch. The input accepts prefixes: @agent-name to pick a subagent, @repo to target a repository, /command for skills, ! to run a shell command as a job, or a PR number. Shift+Enter dispatches and attaches immediately.

What survives the transition

This is the part that decides whether backgrounding is safe for the work you have in flight.

Carries over	Does not
Conversation transcript	Running monitors, which are stopped
Running background shell commands	Commands needing an attached terminal
Subagents and their work
Dynamic workflows
Scheduled /loop tasks
Model, permission mode, effort level
--mcp-config, --settings, --add-dir, --plugin-dir
Name set with /rename

That /loop row is the useful one. A polling loop carries into the background session and keeps firing, which is the documented way to keep one running without a terminal. See scheduled tasks.

Set CLAUDE_DISABLE_ADOPT=1 if you would rather in-flight work stopped than carried over.

Working with a session you cannot see

Peeking is the feature worth learning. Press Space in agent view to see a session’s latest output or question, type a reply, press Enter, and you have answered it without attaching. For a multiple-choice question, press the number key. Tab offers a suggested reply.

To go further in, press the right arrow or Enter to attach. Inside an attached session, the left arrow detaches, Ctrl+Z returns you to where you came from, and /stop ends it.

From the shell instead

claude attach <id>
claude logs <id>
claude stop <id>
claude respawn <id>
claude respawn --all
claude rm <id>
claude daemon status

claude respawn restarts a session and picks up updates, and --all does the lot. For scripting, claude agents --json lists active sessions with id, state, pid, status, waitingFor and cwd; add --all to include completed ones.

File isolation, and the trap in it

Background sessions edit inside isolated git worktrees under .claude/worktrees/ by default, which is what lets several run at once without fighting over the same files. You can turn that off:

{
  "worktree": {
    "bgIsolation": "none"
  }
}

How this compares to Remote Control

	Background sessions	Remote Control
Survives closing the terminal	Yes	No
Reachable from your phone	No	Yes
Runs on	Your machine	Your machine
You interact through	Agent view or claude attach	claude.ai or the Claude app

They answer different questions. Background sessions solve “I want to close this terminal”. Remote Control solves “I want to watch this from elsewhere”. Neither survives the machine shutting down, so for that you want an always-on machine or a cloud session.

Limits

• Quota is consumed per session. Ten parallel background sessions use roughly ten times the quota.
• Local only. They stop when the machine shuts down.
• Research preview. Behaviour may change.

Related: Remote Control sessions, and permission modes, because a background session that hits a prompt sits in the yellow needs-input state until you answer it.

Permission mode barely matters when you are sitting at the terminal. It matters enormously when you are not. A session driven from your phone, hosting a channel, or left running overnight will stop dead at the first permission prompt and wait for an answer you are not there to give.

The six modes

Mode	Runs without asking	Suited to
default (shown as Manual)	Reads only	Sensitive work you are watching
acceptEdits	Reads, file edits, common filesystem commands	Iterating on code you review afterwards
plan	Reads, plus classifier-approved commands where auto is available	Exploring before changing anything
auto	Everything, with a classifier checking each action	Long unattended tasks
dontAsk	Only pre-approved tools	CI and locked-down scripts
bypassPermissions	Everything, no checks	Isolated containers and VMs only

A naming quirk: the mode that reviews every action is labelled Manual in the CLI, VS Code, JetBrains and Desktop, but its config value is default. From v2.1.200 the CLI also accepts manual as an alias.

Switching between them

Shift+Tab cycles default, acceptEdits, plan. The others are not in that cycle by default. dontAsk never appears and must be set with a flag. bypassPermissions only joins the cycle if you started the session with it enabled.

claude --permission-mode plan
claude --permission-mode dontAsk
claude remote-control --permission-mode acceptEdits

As a persistent default, set it in a settings file:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

What acceptEdits actually covers

More than the name suggests. Alongside file edits it auto-approves mkdir, touch, rm, rmdir, mv, cp and sed, including when wrapped in timeout, nice or nohup. Approval only applies to paths inside your working directory or additionalDirectories. Anything outside that, and every other Bash command beyond the read-only set, still prompts.

For remote work this is the pragmatic middle ground: Claude edits freely, you review the diff later, and most prompts disappear.

Auto mode, and why it is not a free pass

Auto mode runs a separate classifier model over each action before it executes, blocking anything that escalates beyond your request, targets infrastructure it does not recognise, or looks driven by hostile content Claude just read. It is available on all plans, though it needs a recent model and can be disabled by administrators.

Blocked by default, among many others: curl | bash, production deploys and migrations, force push, mass deletion on cloud storage, git reset --hard, terraform destroy, printing a live credential into the transcript, and opening a tunnel that exposes a local service to the internet.

Allowed by default: local file operations in your working directory, installing declared dependencies, read-only HTTP, and pushing to branches of the repository you are working in.

You can also state boundaries in conversation. Telling Claude “do not push” makes the classifier block matching actions even where the defaults would allow them. One caveat: boundaries are re-read from the transcript each time, so context compaction can lose one. For a hard guarantee use a deny rule instead.

dontAsk, the mode built for never waiting

dontAsk auto-denies anything that would otherwise prompt. Claude runs only what matches your permissions.allow rules and the read-only command set. The session never waits for input, which is exactly what you want in CI.

The trade-off is obvious once stated: instead of stalling, the work silently fails. For an unattended remote session that is often worse than a pause, so reach for auto first and keep dontAsk for pipelines where you have enumerated what Claude may do.

bypassPermissions, and when not to

This one disables prompts and safety checks entirely, including writes to protected paths. The documentation is blunt that it belongs only in isolated containers and VMs, and it offers no protection against prompt injection.

• You cannot enter it from a session that did not start with it enabled.
• Claude Code refuses to start in this mode as root or under sudo on Linux and macOS.
• The first interactive session shows a warning dialog you must accept once.
• rm -rf / and rm -rf ~ still prompt, as a circuit breaker against model error.
• Cloud sessions ignore defaultMode: "bypassPermissions" from settings files, so a repository cannot start a cloud session in it.

Protected paths

A small set of paths is never auto-approved outside bypass mode, which stops Claude corrupting repository state or its own configuration. Directories include .git, .vscode, .idea, .husky, .devcontainer and .claude. Files include .gitconfig, the shell rc files, .npmrc, .mcp.json and .claude.json.

Worth knowing: an allow rule in settings does not pre-approve these. The safety check runs before allow rules are evaluated.

What you cannot set from your phone

The app restricts modes, and the restrictions differ by session type.

Session	Offered in the app	Unavailable
Cloud session	Accept edits, Plan, Auto	Bypass permissions
Remote Control	Manual, Accept edits, Plan	Bypass permissions, and Auto

So the mode you would most want for a long unattended remote session, auto, cannot be selected from the phone at all. Set it on the host before you leave. The dropdown does reflect the mode the local session is actually in, and updates when you change it in the terminal, with one exception: a session never reports bypass mode to claude.ai.

Choosing for work you will not be watching

• Short task, you will glance at it: acceptEdits.
• Long task, genuinely unattended: auto, set on the host before you leave.
• Pipeline with a known tool list: dontAsk.
• Anything on your real machine: not bypassPermissions.

Related: running on an always-on machine, and channels, where an unanswered prompt stalls the session in exactly the same way.

Remote Control assumes you are there, watching. Scheduling assumes you are not. If what you actually want is for Claude to check on something every few minutes and tell you when it changes, a scheduled task is the tool, and there are three quite different implementations of it.

Three implementations, one idea

	Cloud (Routines)	Desktop tasks	/loop
Runs on	Anthropic cloud	Your machine	Your machine
Machine must be on	No	Yes	Yes
Session must be open	No	No	Yes
Survives restarts	Yes	Yes	Restored on --resume if unexpired
Local files	No, fresh clone	Yes	Yes
Permission prompts	None, runs autonomously	Configurable per task	Inherits from session
Minimum interval	1 hour	1 minute	1 minute

Pick by the third row. /loop is session-scoped, so it stops the moment the session does. That is fine for polling a build you are waiting on, and useless for a nightly job. If you need durable scheduling, the answer is Routines or Desktop tasks, not a longer loop.

Polling inside a session with /loop

Both the interval and the prompt are optional, and which ones you supply changes the behaviour:

You provide	Example	Result
Interval and prompt	/loop 5m check the deploy	Runs on a fixed cron schedule
Prompt only	/loop check the deploy	Claude picks the interval each iteration
Neither	/loop	Runs the built-in maintenance prompt, or your loop.md

Units are s, m, h, d. The interval can lead as a bare token or trail as a clause, so /loop 30m ... and /loop ... every 2 hours both work. Seconds round up to the nearest minute because cron has one-minute granularity, and awkward intervals like 7m or 90m get rounded to something cron can express, with Claude telling you what it chose.

Letting Claude pick the interval

Omit the interval and Claude chooses a delay between one minute and one hour after each iteration, based on what it saw. Short waits while a build is finishing, longer ones once things go quiet. It prints the delay and its reasoning at the end of each pass.

/loop check whether CI passed and address any review comments

Worth knowing: for this kind of request Claude may reach for the Monitor tool instead, which runs a background script and streams each line back. That avoids polling altogether and is usually both faster to react and cheaper in tokens.

The built-in maintenance prompt

A bare /loop runs a prompt Anthropic ships rather than one you wrote. Each iteration works through, in order: continuing unfinished work from the conversation, tending the current branch’s pull request (review comments, failed CI, merge conflicts), then cleanup passes like bug hunts when nothing else is pending.

It deliberately does not start new initiatives, and irreversible actions such as pushing only proceed when they continue something the transcript already authorised. That constraint is what makes a bare /loop reasonable to leave running.

Replacing the default with loop.md

Drop a loop.md file in place and it replaces the built-in prompt. Project level wins over user level:

Path	Scope
.claude/loop.md	Project. Takes precedence when both exist
~/.claude/loop.md	User. Applies in any project without its own

It is plain Markdown with no required structure, written as if you were typing the prompt. Edits take effect on the next iteration, so you can refine it while the loop runs. Content past 25,000 bytes is truncated. Note that it defines the single default for bare /loop, not a list of jobs, and is ignored whenever you pass a prompt yourself.

Stopping one

Press Esc while the loop waits for its next iteration. That clears the pending wakeup. Tasks you created by asking Claude in natural language are not affected by Esc and stay until you delete them.

In self-paced mode Claude can also end the loop itself once the work is done, by calling ScheduleWakeup with stop: true. If an iteration ends without either rescheduling or stopping, Claude Code schedules one fallback wakeup roughly 20 minutes later and ends the loop if that one does not reschedule either.

One-off reminders

No command needed. Describe it and Claude schedules a single-fire task that deletes itself after running.

remind me at 3pm to push the release branch
in 45 minutes, check whether the integration tests passed

Listing and cancelling

Ask in plain language, or reference the tools directly. Each task gets an 8-character ID, and a session holds up to 50 at once.

Tool	Purpose
CronCreate	Schedule a task from a 5-field cron expression, a prompt, and whether it recurs
CronList	List tasks with IDs, schedules, and prompts
CronDelete	Cancel a task by ID

Two behaviours that will surprise you

Jitter

The scheduler deliberately offsets fire times so every session does not hit the API on the same wall-clock second. Recurring tasks fire up to 30 minutes after the scheduled time, or up to half the interval for anything more frequent than hourly. One-shot tasks set for the top or bottom of the hour fire up to 90 seconds early.

The offset comes from the task ID, so it is stable for a given task. If exact timing matters, avoid :00 and :30: schedule 3 9 * * * rather than 0 9 * * * and the one-shot jitter does not apply.

Seven-day expiry

Recurring tasks expire seven days after creation. The task fires one last time and deletes itself, which bounds how long a forgotten loop can run. That includes dynamically paced loops. For anything that needs to outlive a week, use Routines or Desktop tasks rather than recreating the loop.

Cron reference

CronCreate takes standard 5-field expressions: minute hour day-of-month month day-of-week.

Expression	Meaning
*/5 * * * *	Every 5 minutes
0 * * * *	Hourly on the hour
7 * * * *	Hourly at 7 past
0 9 * * *	Daily at 9am local
0 9 * * 1-5	Weekdays at 9am local
30 14 15 3 *	15 March at 2:30pm local

All times are your local timezone, not UTC. Day-of-week is 0 or 7 for Sunday through 6 for Saturday. Extended syntax such as L, W, ? and name aliases like MON is not supported. When both day-of-month and day-of-week are constrained, a date matches if either field matches, following vixie-cron semantics.

Limitations

• Tasks fire only while Claude Code is running and idle. A scheduled prompt lands between turns, never mid-response. Close the terminal and nothing fires.
• No catch-up. If the scheduled time passes while Claude is busy, the task fires once when Claude goes idle, not once per missed interval.
• A fresh conversation clears everything. --resume or --continue restores recurring tasks created within seven days and one-shots whose time has not passed. Background Bash and monitor tasks are never restored.
• Symlinked .claude directories fail. From v2.1.216 scheduling errors out when that directory or the task file is a symlink, where earlier versions wrote through the link.

To disable the scheduler entirely, set CLAUDE_CODE_DISABLE_CRON=1. The cron tools and /loop both become unavailable and existing tasks stop firing.

How this sits next to Remote Control

They solve opposite halves of the same problem. Scheduling handles work that should happen without you. Remote Control handles work you want to watch and redirect from wherever you are. The pairing that actually gets used: leave a /loop running in a session, attach Remote Control to it, and check the loop’s findings from your phone.

Since /loop needs the session open, it inherits the same constraint as Remote Control, so an always-on machine helps both. To react to events instead of polling for them, see channels.

Two Claude Code flags sound almost identical and do unrelated things. --cloud starts a session on Anthropic’s infrastructure. --remote-control exposes a session running on your own machine. Both end up visible at claude.ai/code, which is why the two get mixed up constantly.

Where the code actually runs

	Claude Code on the web	Remote Control
Executes on	An Anthropic-managed VM	Your machine
Your files	Cloned from GitHub, or uploaded as a bundle	Already there, untouched
Your MCP servers	Not available	Available
Machine must stay on	No	Yes
Starts with	claude --cloud "task"	claude remote-control

Everything else follows from the first row. A cloud session cannot read a file you have not pushed, and it cannot reach a local database through an MCP server on your laptop. In exchange, it keeps running when you close the lid.

Starting a cloud session from the terminal

claude --cloud "Fix the authentication bug in src/auth/login.ts"

The catch that trips people up on their first run: the VM clones your current branch from GitHub, not from your working directory. Local commits that are not pushed do not exist as far as the cloud session is concerned. Push first.

From v2.1.195 the CLI shows a live checklist while the container starts, covering the clone and any setup script. Anything you type while it provisions is queued and delivered once the session is ready. Use /tasks to check progress, or open the session on claude.ai or your phone.

The older --remote spelling still works as a deprecated alias for --cloud. Worth knowing if you find it in an old script, and worth renaming while you are there, because --remote reads like --remote-control and is not.

Repositories that are not on GitHub

If the repository has no GitHub remote, Claude Code bundles it and uploads it directly. That fallback triggers on its own, or you can force it with CCR_FORCE_BUNDLE=1:

CCR_FORCE_BUNDLE=1 claude --cloud "Run the test suite and fix any failures"

Bundling has real limits. The directory needs at least one commit. The bundle must be under 100 MB, and larger repositories degrade first to the current branch only, then to a squashed snapshot of the working tree. Untracked files are excluded, so git add anything you want the session to see. A session created from a bundle cannot push back to a remote unless you also have GitHub authentication configured.

Pulling a cloud session back to your terminal

This is the direction that matters if you started something in the browser and want to finish it locally. Four routes, all the same underlying operation:

• claude --teleport for an interactive picker, or claude --teleport <session-id> for a specific one
• /teleport or /tp inside a session you already have open
• /tasks, then press t
• Open in CLI in the web interface, which copies a command to paste

Teleport checks four things before it will resume:

Requirement	Detail
Clean git state	No uncommitted changes. You are prompted to stash
Correct repository	A checkout of the same repository, not a fork. From v2.1.199 an unparseable remote such as an SSH host alias is accepted after a confirmation prompt, but only when owner and repository name match
Branch pushed	The cloud session’s branch must exist on the remote. Teleport fetches and checks it out
Same account	Authenticated to the same claude.ai account that owns the session

--teleport is not --resume. --resume reopens a conversation from this machine’s local history and never lists cloud sessions.

The overlap nobody mentions

Here is the part worth knowing if you land on this site from an error message. --teleport connects through the same Remote Control session infrastructure that cloud sessions use. So when teleport fails, it fails using Remote Control wording, even though you never ran /remote-control.

You may see any of these while teleporting:

• Remote Control session expired
• Access denied
• Remote Control may not be available for this organization

The connection token is short-lived and scoped to your account. Run /login locally to refresh credentials and reconnect, and confirm you are on the account that owns the session. The third message means an Owner has not enabled cloud sessions for your organization, which is a different toggle from the Remote Control toggle.

Keeping your phone useful after teleporting

When you teleport, the terminal gets its own copy of the session. New work stays local and stops appearing in the cloud session on claude.ai or in the mobile app. If you want to keep steering from your phone after pulling the session down, start Remote Control in the local session:

/remote-control

That is the clean way to use both features together: cloud for the unattended run, Remote Control for the part where you want to watch and interject.

Two patterns worth stealing

Plan locally, execute remotely

Start in plan mode so Claude explores and proposes an approach without editing anything, then hand the agreed plan to the cloud.

claude --permission-mode plan
# agree the plan, commit and push it, then:
claude --cloud "Execute the migration plan in docs/migration-plan.md"

You keep control of strategy and the cloud does the long autonomous part. Note the commit and push step: the VM clones from GitHub, so a plan sitting uncommitted on your disk is invisible to it.

Parallel tasks

Each --cloud command is its own session and they run simultaneously.

claude --cloud "Fix the flaky test in auth.spec.ts"
claude --cloud "Update the API documentation"
claude --cloud "Refactor the logger to use structured output"

Monitor all of them with /tasks. Bear in mind that parallel sessions consume your rate limits proportionately, since there is no separate compute charge but the usage is shared.

Isolation

• Each session runs in its own isolated Anthropic-managed VM.
• Network access is limited by default and can be disabled entirely. Even with network access off, Claude Code still reaches the Anthropic API, which means data can leave the VM by that route.
• Git credentials and signing keys are never inside the sandbox. Authentication goes through a proxy using scoped credentials.

Limits to plan around

• Rate limits are shared with all your other Claude and Claude Code usage. Parallel tasks eat them faster.
• Pushing results needs GitHub. GitLab, Bitbucket and others can be sent up as a bundle, but the session cannot push back.
• IP allowlisting breaks it entirely. Cloud sessions call the Anthropic API from Anthropic infrastructure, not your network, so every session fails with an authentication error until Anthropic-hosted services are exempted.
• Zero Data Retention organizations cannot use it, nor /web-setup. The same constraint rules out Remote Control.
• Sessions expire on inactivity and the VM is reclaimed. Reopening from claude.ai provisions a fresh VM with your conversation history restored.

Which one you want

Use Remote Control when the work has already started on your machine and you want to keep an eye on it from somewhere else. Use Claude Code on the web when the work has not started, you want it to run unattended, or the repository is not even cloned locally. They compose well: cloud for the long run, teleport to bring it home, Remote Control to keep watching from your phone.

Side-by-side breakdown on Remote Control vs Claude Code on the web, and the wider set of options in articles.