The features in this module have one thing in common: they matter when a task is large, risky, or unattended. A plan before the first change, a backup model when the first one is out, a classifier deciding what still needs asking, a sandbox around the file system and the network, a run with no terminal at all — and a set of switches an organization sets centrally.
Plan first, type later — and how deeply Claude thinks
Plan mode draws a line between research and change. Claude may read and search but writes nothing and runs no commands; what comes out is a proposal you read, extend, or discard. Only your approval unlocks writing. The gain lies less in the plan itself than in the order of things: whatever was misunderstood surfaces before the first file is touched.
There are three ways in: /plan — optionally with the task attached, such as /plan fix the auth bug — the --permission-mode plan flag at launch, or Shift+Tab, which cycles through the permission modes. Ctrl+G opens the current plan in whatever editor $VISUAL or $EDITOR names, so longer edits happen there instead of in the prompt. If you want Opus for the thinking and Sonnet for the doing, use the opusplan alias: it resolves to Opus during plan mode and to Sonnet during execution — which makes every mode toggle a model switch that starts a fresh prompt cache:
claude --model opusplan "redesign the database schema for multi-tenancy" How long Claude reasons before answering is a separate dial. Option+T (macOS) or Alt+T toggles extended thinking for the session. /effort takes low, medium, high, xhigh, max, or ultracode; which levels are offered depends on the model, and both max and ultracode apply to the current session only. auto is not another level — it resets to the model default. Across sessions, CLAUDE_CODE_EFFORT_LEVEL holds a preference. Two words act straight from the prompt: ultrathink raises reasoning depth regardless of the effort setting, and ultracode triggers a dynamic workflow — that keyword was workflow until v2.1.160, and to type the word without triggering a run, set workflowKeywordTriggerEnabled to false.
MAX_THINKING_TOKENS is not an on/off switch but the ceiling of the thinking budget; it reaches at most the model’s maximum output tokens minus one. The value 0 disables thinking on the Anthropic API — except on Fable 5, which always thinks. On third-party providers 0 does something else: the thinking parameter is simply omitted, and the model may still think. The distinction by model generation belongs to a different variable: CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING takes adaptive reasoning away from Opus 4.6 and Sonnet 4.6 and, from v2.1.111, has no effect on Fable 5, Sonnet 5, or Opus 4.7 and later.
The two dials together set the gait for hard design questions — plan mode for the order of work, a high effort level for the depth, plus the model routing:
claude --permission-mode plan --effort high --model opusplan "migrate from REST to GraphQL"When the model is overloaded: the backup chain
When the main model is unavailable, the request need not fail. Claude Code can switch to a backup model if the primary one is overloaded or unreachable, or returns another server error that retrying will not fix. A switch is deliberately withheld for the other classes: problems with credentials, with billing, with a rate limit, with the size of the request, or with the transport itself all stay in the normal retry logic. The switch holds for the rest of the current turn; your next message starts with the primary model again, and a notice in the session shows that a switch happened.
For a single session the --fallback-model flag with a comma-separated list is enough:
claude --fallback-model sonnet,haiku To keep the chain around, it belongs in the fallbackModel setting as an array:
{
"fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
} Three rules are worth remembering. The flag beats the setting. Each entry may be a model name or an alias; the entry "default" resolves to whichever model is standard for your kind of account. After duplicates are removed, at most three models remain; anything beyond that is ignored. And unlike most array settings, fallbackModel does not merge across settings files: the highest-precedence file supplies the entire chain. Together with availableModels that is the only exception to the merge rule.
Ultraplan: moving the drafting into the cloud
Ultraplan moves the part that takes longest into the cloud: the drafting. A Claude Code on the web session works on your task in plan mode while your terminal stays free. The finished draft lands in a browser view that can do more than a terminal — commenting on sections individually instead of replying to the whole text.
There are three ways to start it: /ultraplan with your task behind it, writing the word ultraplan anywhere in a normal prompt, or choosing "No, refine with Ultraplan on Claude Code on the web" in the approval dialog of a finished local plan. The first two ask for confirmation first; the third does not, because the choice in the dialog is the confirmation. If Remote Control is active, it disconnects at launch — both features occupy the same channel.
While the cloud works, a status line sits above your input: ◇ ultraplan while research and drafting are under way, ◇ ultraplan needs your input when there is a question, and ◆ ultraplan ready once the draft is up for review. /tasks opens a detail view with the session link, the activity, and a stop action; stopping archives the cloud session and leaves nothing behind in your terminal. In the browser you highlight passages and comment on them, react to a section with an emoji, and ask for revisions as often as you like.
Once the plan looks right, you choose in the browser where it runs:
- Execute in the cloud — Claude implements the plan in the same session, and you review the diff in the browser and open the pull request from there
- Back to the terminal — the plan arrives in your CLI, where you choose between carrying on in the running conversation, a fresh session holding only the plan, and simply saving it to a file
/ultraplan migrate the auth service from sessions to JWTsUltraplan requires access to Claude Code on the web and a GitHub repository. Because the session runs on Anthropic’s infrastructure, the feature is not available on Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry. If you have no cloud environment yet, the first launch creates one.
Auto mode and the question of who gets asked when
Auto mode inverts the prompting: instead of asking you at every tool call, a classifier model of its own reviews the action first and blocks whatever escalates beyond your request, targets unfamiliar infrastructure, or looks driven by content Claude merely read. Explicit ask rules still force a prompt. It is meant for work that should largely run on its own while you still want a guardrail around the risky parts.
It is driven like every other mode — choose auto among the permission settings, or reach it by cycling with Shift+Tab wherever your setup offers the mode. What it should treat as trusted infrastructure is described by an organization in the autoMode settings block.
Out of the box the classifier is cautious about anything that looks like data leaving, risky shell execution, or changes reaching production. When a check stalls, the spinner turns red — so it is visible that a check is running rather than a tool. Your own repos, internal domains, buckets, or services that should count as normal belong in autoMode.environment.
When customizing autoMode.allow, autoMode.soft_deny, autoMode.hard_deny, and autoMode.environment, one detail decides everything: without the literal string "$defaults" in the array, your list replaces the built-in rules entirely. With it, the default entries are spliced in at exactly that position, and your own can sit before or after them.
Inside the classifier the order is fixed. hard_deny blocks unconditionally; neither an exception from allow nor your stated intent gets past it. soft_deny blocks as well but can be overridden — by a matching allow rule or by a request that names the intent clearly: "force-push this branch" clears the soft block, a vague "clean up the repo" does not. That has a consequence an organization should know: because allow acts as an exception inside the classifier, a self-added allow entry can override a soft_deny from managed settings — the combination is additive, not a hard policy boundary. If the classifier blocks three times in a row or twenty times in total, auto mode pauses and Claude Code goes back to prompting; any allowed action resets the consecutive counter, and the thresholds themselves are not configurable.
Three subcommands make the rules visible before you rely on them: claude auto-mode defaults prints the built-in rules, claude auto-mode config shows the effective merged version built from those and your additions, and claude auto-mode critique has your own rules reviewed. Here is what an addition that keeps the defaults looks like:
{
"autoMode": {
"allow": ["$defaults", "Deploying to staging is allowed"],
"soft_deny": ["$defaults", "Never run migrations outside the migrations CLI"],
"hard_deny": ["$defaults", "Never send repo contents to third-party APIs"],
"environment": ["$defaults", "Internal API: api.corp.example.com"]
}
} The permission modes form a spectrum. default reads freely and asks about anything beyond that. acceptEdits removes the prompt for file edits for the session, except for protected directories. plan is the research mode from above. auto hands the decision to the classifier. dontAsk runs pre-approved tools only and denies the rest. bypassPermissions skips most prompts — since v2.1.126 including writes to previously protected paths such as .claude/, .git/, or shell configuration files, while the most consequential removal commands still ask. --dangerously-skip-permissions is the shorthand for it; the deliberately uncomfortable name names the trade you are making.
At launch, --permission-mode picks the mode for that one run and overrides defaultMode from your settings files — handy for making a one-off automation stricter without touching the config. The flag works together with -p as well. dontAsk is the one mode missing from the Shift+Tab cycle — you reach it through this flag or through defaultMode in settings, just not by cycling.
claude --permission-mode plan "draft the migration"
claude -p "audit dependencies" --permission-mode dontAskSo that most of your sessions start in the mode you want without passing a flag, the default belongs in settings:
{
"permissions": {
"defaultMode": "acceptEdits"
}
}And this is how you describe to the classifier the infrastructure it may trust:
{
"autoMode": {
"environment": [
"Source control: github.example.com/acme-corp and all repos under it",
"Trusted internal domains: *.corp.example.com, api.internal.example.com"
]
}
} Auto mode is by now available on every provider by itself — the Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry. The earlier opt-in through CLAUDE_CODE_ENABLE_AUTO_MODE=1 applied from v2.1.158 to v2.1.206; since v2.1.207 the variable is only accepted for compatibility and does nothing. Two other conditions remain. First the model: on the Anthropic API and Claude Platform on AWS, Opus 4.6 or later, Sonnet 4.6 or later, or Fable 5 — on the other providers only Sonnet 5, Opus 4.7 or later, and Fable 5. Second the organization: on Team and Enterprise plans an Owner has to enable the mode first, and permissions.disableAutoMode in managed settings takes it out of the selection entirely.
Two newer settings belong here. enforceAvailableModels (v2.1.175) makes the allowlist in availableModels bind the default model as well: if the default would resolve to a disallowed model, the first allowed one takes over, and user or project settings can no longer widen a managed list. footerLinksRegexes (v2.1.176) adds extra badges to the footer when a regular expression matches a turn’s output — each entry brings a pattern, a URL template, and optionally a label.
Without a terminal session: scripted runs and the sandbox
With claude -p, Claude Code runs without an interactive surface: the prompt comes as an argument, the answer goes to stdout, and it slots into shell pipelines and automation. --output-format json returns it structured when a script has to process it further, and for fully automated runs --permission-mode bypassPermissions takes the prompts out. Hooks and Bash calls in such sessions read the active reasoning depth from $CLAUDE_EFFORT; ultracode is not a level of its own there and reports as xhigh.
/cd moves a running session to another working directory without destroying the prompt cache: the new directory’s CLAUDE.md is appended as an extra message instead of rebuilding the system prompt. The session also relocates to the new directory’s project storage, so --resume and --continue find it there. Together these pieces make runs nobody has to watch:
# Automated code review in CI
git diff HEAD~1 | claude -p "review these changes for security issues" \
--output-format json \
--permission-mode bypassPermissions
# Generate docs for changed files
claude -p "generate JSDoc for all functions in $CHANGED_FILE" \
--print --no-session-persistence Sandboxing draws the line one level down, in the operating system rather than in the permission logic. The sandboxed variant of Bash is available on macOS, Linux, and WSL2; native Windows does not support it — there, Claude Code belongs inside a WSL2 distribution. In-session, /sandbox toggles it and stores the choice in .claude/settings.local.json; across projects you set sandbox.enabled to true in ~/.claude/settings.json. There is no launch flag for it, and it is off by default. After that Claude reaches only approved paths and the network targets you described — the choice when someone else’s code is in play.
The network side is governed by sandbox.network.allowedDomains and sandbox.network.deniedDomains. The first list opens outbound traffic, the second closes individual targets again — including when a wildcard in the first list would permit them. Deny always wins, and both lists understand patterns such as *.example.com:
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"],
"deniedDomains": ["uploads.github.com"]
}
}
} In managed installations the block list is deliberately not negotiable: every source — managed, user, project, local — contributes to deniedDomains, and allowManagedDomainsOnly changes nothing about that. What the flag does decide is the set of scopes allowedDomains may come from. A block someone set at the user level therefore cannot be silently dropped by an enterprise policy.
If the sandbox helper binaries live in unusual places on Linux or WSL2, sandbox.bwrapPath and sandbox.socatPath name the bubblewrap and socat binaries directly and replace the lookup through PATH. Both keys are read from managed settings only — in a user or project file they have no effect:
{
"sandbox": {
"bwrapPath": "/usr/local/bin/bwrap",
"socatPath": "/usr/bin/socat"
}
} Managed settings are the lever for enterprise use in general: they are rolled out with each system’s own means: a plist on macOS, the Registry on Windows, plus managed configuration files and the fragments in managed-settings.d/, which fold together in alphabetical order. They sit above user settings. That is separate from managed memory files such as an organization-wide CLAUDE.md. Sandbox and scripted operation combine, by the way:
# Headless run (sandboxing comes from sandbox.enabled, not from a flag)
claude -p "analyze the security of this codebase" \
--permission-mode plan \
--output-format jsonA second opinion mid-turn: the advisor tool
The advisor tool pairs two models in one session. The main model does the work, and at the moments that count — before committing to an approach, when the same error keeps returning, before declaring a task done — it asks a second, stronger model for its read. The advisor receives the full conversation including every tool call and result and returns guidance; execution stays with the main model. This pays off on long, multi-step tasks where most steps are routine but the quality of the plan decides the outcome — for short work, or when every step needs the strongest model anyway, switching the main model is the better answer.
The advisor becomes active by having an advisor model set, in one of three ways: /advisor mid-session (the choice is saved as advisorModel in your user settings and persists), advisorModel straight in the settings file, or --advisor for a single launch. The session then shows a notification line carrying an "experimental" label. The advisor must be at least as capable as the main model. To turn the whole thing off there is CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1: /advisor disappears, a configured advisorModel is ignored, and --advisor is still accepted but has no effect — so existing scripts keep running. Because the tool runs server-side on Anthropic’s infrastructure, it requires the Anthropic API and is unavailable on Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, and Microsoft Foundry.
Searching without the detour on macOS and Linux
On native builds for macOS and Linux, the Glob and Grep tools give way to the embedded programs bfs and ugrep, reachable through the Bash tool. The difference is the detour that disappears: Claude issues a Bash command instead of calling a separate tool and waiting for its answer — in large repositories that makes searching noticeably faster.
For Windows and for installations via npm nothing changes; the original tools stay in use there. Likewise CLAUDE_CODE_GLOB_HIDDEN, CLAUDE_CODE_GLOB_NO_IGNORE, and CLAUDE_CODE_GLOB_TIMEOUT_SECONDS keep applying wherever those tools are still in play.
How long session files stay around
cleanupPeriodDays decides how long session files and other application data stay before being deleted at startup. The default is 30 days, the minimum is 1, and the value 0 is rejected with a validation error. The same age cutoff governs the cleanup of orphaned worktrees at startup — leftovers from crashed or interrupted parallel runs, and only where nothing is left hanging in them: no changes outside a commit, no files git does not know about, nothing waiting to be pushed; anything you created yourself with --worktree is never touched by that sweep. If Claude Code cannot read a settings file, the sweep pauses with a warning in /status until the file is fixed:
{
"cleanupPeriodDays": 14
} If nothing should be written in the first place in non-interactive runs, there is --no-session-persistence alongside -p; in the Agent SDK the equivalent is persistSession: false. To suppress transcripts generally, set CLAUDE_CODE_SKIP_PROMPT_HISTORY.
Wiping everything for one project at once
When a retention period is not enough and a project’s state should be gone right now, claude project purge is the tool — available from v2.1.124. Gone afterwards are the transcripts, the task lists, the debug logs, whatever was recorded of file edits and of your input, and the project entry along with them:
# Preview what would be deleted
claude project purge --dry-run
# Purge state for the current project
claude project purge
# Skip the confirmation prompt
claude project purge --yes
# Interactively choose which items to remove
claude project purge --interactive
# Purge state for every project at once
claude project purge --all The flags combine: claude project purge --all --dry-run shows, across all projects, what a full wipe would take without touching anything. -y skips the confirmation, -i lets you pick item by item, and a path after the command addresses a project other than the current one.
Switches that exist only as environment variables
A few capabilities have neither a command nor a setting — they hang on an environment variable. The ones below are worth knowing because they either help while debugging or are needed in managed installations.
OTEL_LOG_RAW_API_BODIES writes the full Messages API requests and responses as OpenTelemetry log events. 1 keeps them inline, truncated at the content limit (60 KB by default); file:<dir> writes them to disk untruncated and leaves only a pointer in the event. The bodies contain the entire conversation, which is why switching this on is at the same time consent to everything OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS, and OTEL_LOG_TOOL_CONTENT would reveal — and why the logs afterwards deserve the same care as secrets.
OTEL_RESOURCE_ATTRIBUTES takes your own key=value pairs, comma-separated, without spaces and with special characters percent-encoded. Claude Code attaches them as labels on every metric datapoint and event and additionally sends them in the resource block — which lets you slice usage in your own backend by team, department, or cost center. Built-in attributes such as user.id or session.id are never overwritten by them. To keep cardinality low, drop the per-datapoint labels with OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false; in the resource block they stay.
CLAUDE_CODE_USE_POWERSHELL_TOOL controls the PowerShell tool, and the default depends on the platform: on Windows without Git Bash it is on by itself and 0 switches it off; on Windows with Git Bash the rollout is progressive, so you choose with 1 or 0. On Linux, macOS, and WSL only 1 enables the tool, and that requires pwsh on your PATH. Once enabled, Claude runs PowerShell commands directly instead of routing them through Git Bash.
DISABLE_UPDATES=1 blocks every update path, including a hand-started claude update and claude install. It is the stricter option next to DISABLE_AUTOUPDATER, which only prevents automatic updates, and it is meant for installations distributed through a channel of your own whose version must not change.
CLAUDE_CODE_SAFE_MODE=1 — equivalent to --safe-mode — starts with every customization left out: CLAUDE.md, skills, plugins, hooks, MCP servers, custom commands and agents, output styles, workflows, themes, keybindings, the status line, and LSP servers stay out of the picture. One exception is deliberate: whatever managed settings prescribe still applies. The mode therefore answers the question of whether a misbehavior comes from your configuration or not.
CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1 — or disableBundledSkills in settings — removes the bundled skills and workflows entirely. Built-in commands such as /init, by contrast, stay typable and only disappear from what the model sees; for /doctor there is DISABLE_DOCTOR_COMMAND instead. Skills from plugins, from .claude/skills/, and from .claude/commands/ are untouched.
CLAUDE_CODE_HIDE_CWD=1 makes the working directory disappear from the startup banner. Useful for recordings and shared screens where the path alone gives away more than intended — your operating-system username, for instance.
CLAUDE_CODE_NATIVE_CURSOR=1 shows the terminal’s cursor at the input caret instead of the block Claude Code draws. The terminal’s settings for blinking, shape, and focus apply again — which counts when a particular cursor style is configured or accessibility is involved.
CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE has had no effect since v2.1.160. The variable used to pin fast mode to Opus 4.6 instead of following the current default; Opus 4.6 no longer supports fast mode at all.
CLAUDE_CODE_RESUME_PROMPT replaces what gets inserted when a session that broke off mid-turn picks up again; the default is Continue from where you left off.. Scripts that start and resume agents over long stretches can leave a far more directive boot instruction here. An empty string means: back to the default.
CLAUDE_CODE_ENABLE_FEEDBACK_SURVEY_FOR_OTEL=1 keeps the "How is Claude doing?" quality survey alive where nonessential Anthropic-bound traffic is shut off anyway: the ratings land as OTEL events at your own collector and nowhere else. One of the three blocks has to be in place — CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, or DO_NOT_TRACK; without one the variable does nothing. Precedence stays with CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY and with whatever policy your organization has set for product feedback.
ANTHROPIC_WORKSPACE_ID names the workspace for workload identity federation. If your federation rule covers more than one workspace, the token exchange needs this value to settle on one — without it there is no criterion to choose by and the exchange fails. Where the rule is scoped to exactly one workspace, leave the variable unset:
# Capture full OTEL telemetry while reproducing an API bug
OTEL_LOG_RAW_API_BODIES=1 claude --print 'reproduce the failure'
# Slice metrics by team and cost center in your OTEL backend
OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123" \
claude
# Enable PowerShell tool on macOS or Linux
CLAUDE_CODE_USE_POWERSHELL_TOOL=1 claude
# Block all updates on a locked-down machine
DISABLE_UPDATES=1 claude
# Hide the working directory in the startup banner
CLAUDE_CODE_HIDE_CWD=1 claude
# Use the terminal's own cursor at the input caret
CLAUDE_CODE_NATIVE_CURSOR=1 claude
# Override the resume continuation message for an agent boot script
CLAUDE_CODE_RESUME_PROMPT="Resume the migration and stop after the next test run." \
claude --resume
# Route the session quality survey through your OTEL collector
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
CLAUDE_CODE_ENABLE_FEEDBACK_SURVEY_FOR_OTEL=1 claude
# Workload identity federation with a multi-workspace rule
ANTHROPIC_WORKSPACE_ID=ws_01abcd... claudeMoving back and forth between terminal and cloud
At claude.ai/code, Claude Code on the web does the work on infrastructure that Anthropic operates. A cloud session keeps going when you close the browser, and you can follow it on the move from the Claude app.
From the terminal, claude --cloud with a task description starts such a session; --remote is only a deprecated alias for it now. Claude clones your repository from GitHub — so push local commits first — works through the task on its own, and can open a pull request at the end. Several calls run in parallel.
The other direction is /teleport, short /tp: it opens a picker, fetches the branch and the full conversation history of the cloud session into your local terminal, and lets you carry on there; a claude.ai subscription is required. Together with launching into the cloud this makes a loop where work runs wherever it currently fits better.
/autofix-pr spawns a cloud session that watches the pull request of your checked-out branch: when CI fails or someone comments in review, Claude looks for the cause and pushes a fix. The command finds the open PR through gh pr view, which is why the gh CLI has to be present and why a different PR has to be checked out first. Without an argument the brief covers every CI failure and every review comment; a prompt narrows it, for example /autofix-pr only fix lint and type errors. The Claude GitHub App has to be installed on the repository, because the PR webhooks come through it:
# Plan locally, execute in the cloud
claude --permission-mode plan
# ... finalize plan, commit, push ...
claude --remote "Execute the migration plan in docs/migration-plan.md"
# Pull the cloud session back when done
/teleport The cloud environment ships the usual runtimes — among them Node.js, Python, Go, Rust, Java, Ruby, Docker, and PostgreSQL — and works with roughly 4 vCPUs, 16 GB of memory, and 30 GB of disk; network reach is governed by the environment’s access level. What comes from the repository applies in the cloud too: CLAUDE.md, settings, MCP servers, hooks, and the skills under .claude/skills/ — they are part of the clone. What does not travel is whatever sits on your machine under ~/.claude/; in exchange, a cloud session additionally loads the skills enabled for your claude.ai account. Project configuration therefore belongs in the repo.
Pointing the PR badge at your own review tool
The PR badge in the footer normally points at GitHub. prUrlTemplate aims it at a different review tool — GitLab, Bitbucket, or an internal surface. The template is a URL pattern with the placeholders {host}, {owner}, {repo}, {number}, and {url}, filled from the PR URL that gh reports. It affects the badge and the summaries of tool results, not references such as #123 in Claude’s prose. The block below only shows the shape of the setting — which placeholders get substituted is decided by the list above:
{
"prUrlTemplate": "https://gitlab.example.com/org/repo/-/merge_requests/{number}"
}Where a new worktree branches from
Git worktrees allow several checked-out branches side by side, with no stashing and no branch switching; claude --worktree creates one and links it to a directory of that name. What that worktree branches from is governed by worktree.baseRef (since v2.1.133). fresh — the default — takes origin/<default-branch> and therefore a tree in the state of the remote; head takes your local HEAD. A branch name is not an accepted value:
{
"worktree": {
"baseRef": "head"
}
} The difference counts as soon as you have unpublished work: with head, unpushed commits and the state of the feature branch are present in the new worktree. From inside a linked worktree, head means that worktree’s own HEAD, not the main checkout’s. The setting applies to --worktree, to the EnterWorktree tool, and to the worktrees isolated subagents work in.
Claude at the graphical interface
Computer use hands Claude the keyboard, mouse, and screen on macOS. In one conversation an app can be written, compiled, launched, clicked through, and captured in a screenshot. It is meant for tasks that do not work without an interface: verifying a native build, testing a surface end to end without setting up a test framework, reproducing and fixing a layout problem, or driving a tool that exists only graphically.
Claude reaches for more precise means first: an MCP server, the shell, or the Chrome integration. Computer use is the fallback for everything those cannot reach — native programs, simulators, software without an interface.
Technically it is a built-in MCP server named computer-use, shipped switched off: run /mcp in a session, find the server in the list, and enable it; the decision persists per project. On first use macOS asks for Accessibility and Screen Recording permissions — after granting Screen Recording a restart may be needed. From then on every app is approved individually: Claude asks at first access, the approval holds for the running session, and programs with broad reach such as terminals, Finder, or System Settings carry an extra warning.
While Claude works, the other visible windows are hidden so only approved programs are in play; after the turn they come back. Your terminal stays visible and is excluded from the screenshots — so Claude never sees its own output. Esc anywhere or Ctrl+C in the terminal aborts immediately, brings the windows back, and returns control to you. The machine is held exclusively meanwhile: the lock takes effect from the first action, and since v2.1.195 only exiting the session releases it, not finishing the task.
The requirements are macOS, a Pro or Max plan, signing in through claude.ai, and an interactive session — with -p the feature is unavailable, and so it is on Team and Enterprise plans. It cannot be reached through Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry; anyone working exclusively through one of those needs a separate claude.ai account for it. If computer-use does not show up in /mcp at all, one of these conditions is unmet.
What else is in the toolbox
The rest of the advanced toolbox deserves at least a mention. Background tasks let long runs continue while you keep talking in the foreground. For repetition there are two different things: /loop is a bundled skill that repeats a prompt while the session stays open — with an interval or without, in which case Claude paces itself — whereas /schedule (alias /routines) creates routines that run on Anthropic’s infrastructure and do not need you at the machine. /resume, /rename, and /teleport make sure a session can move between terminal, browser, and desktop app.
On top of that come the everyday pieces: dictation with /voice, the browser connection through --chrome, driving a local session from the browser with /remote-control, short interactive lessons via /powerup, persistent task lists, and the worktree flows from above. All of it hangs on the same permission system — which is why advanced usage is mostly about pairing the right mode with the right surface.