Letting Claude Code work autonomously: auto mode, the Ralph loop and tmux

The idea is tempting: you give Claude Code a sizeable task in the evening, go to bed, and find working code with green tests the next morning. To get there, you have to work around two habits of Claude Code. It asks permission before it does things. And it stops as soon as it thinks it is done, even when the tests are still red.

For the first problem, --dangerously-skip-permissions was the standard answer for a long time. It is no longer the best route. For the second, there is the Ralph loop. This is the state of things as of September 2026.

Problem 1: Claude keeps asking for permission

In manual mode (called Manual in the CLI), Claude Code asks permission before it edits files, runs shell commands or goes onto the network. Come back after an hour and it may have spent all that time waiting for a single Enter.

Auto mode: the default choice for long tasks

Claude Code now has an auto mode. In it, a second model, the classifier, reviews each action instead of you. Ordinary work in your project folder goes ahead; risky actions are stopped. By default the classifier blocks, among other things: downloading and executing code (like curl | bash), sending sensitive data out, production deploys and migrations, force pushes, git reset --hard, and permanently deleting files that existed before the session started.

On Pro, Max and Team plans, sessions start in auto mode by default. Otherwise you switch it on like this:

claude --permission-mode auto

The documentation describes auto mode as the mode for long tasks. A sandbox or container adds protection on top, but is not required.

--dangerously-skip-permissions: containers only

The flag still exists. It turns on bypassPermissions mode: every permission prompt and safety check disappears, including for writes to protected paths. The documentation is explicit: only use it in isolated environments such as containers, VMs or dev containers without internet access, where Claude Code cannot damage your own system. Run as root, Claude Code refuses the flag unless it is inside a recognised sandbox.

Anthropic ships a dev container configuration that runs Claude Code as a regular user. For fully unattended work inside such a container, the documentation gives this example:

claude -p "write unit tests for the billing module" --dangerously-skip-permissions

The difference in one sentence: in auto mode a second model is watching; in bypass mode nobody is.

What CLAUDE.md does and doesn't do

Claude Code reads a CLAUDE.md in the root of your project at the start of every session. Put in how the project works: stack, conventions, how to run the tests. The more concrete, the better Claude follows it.

# CLAUDE.md

## Stack
- Backend: PHP (Laravel 11)
- Frontend: React + Vite
- Database: MySQL 8

## How we work
- Run tests: php artisan test
- New code goes in /app and /resources
- Database changes only via migrations

Prohibitions don't belong there, or at least not only there. According to the documentation, Claude treats CLAUDE.md as context, not as enforced configuration. What is truly off limits goes into deny rules in .claude/settings.json. Those apply in every mode, including bypassPermissions.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Edit(./.env)",
      "Bash(git push *)"
    ]
  }
}

One caveat: a Bash rule matches the text of the command. Bash(git push *) stops git push origin main, but not git -C . push origin main. If something must be blocked without exception, use a PreToolUse hook or the sandbox.

Problem 2: Claude stops too early

Permissions don't solve the second problem. Claude thinks it is done while the tests are still failing, and waits for you. That is what the Ralph loop is for.

Why is it called Ralph Wiggum?

Ralph Wiggum is the boy from The Simpsons who cheerfully carries on no matter how often things go wrong. Developer Geoffrey Huntley described the technique in July 2025 with the line "Ralph is a Bash loop": a while loop that feeds the same prompt to a coding agent over and over. Each round, the agent finds the previous round's work in the files.

The official plugin

Anthropic turned it into an official plugin. In the plugin directory it is called Ralph Loop; in the Claude Code repository it lives in the ralph-wiggum folder. The plugin works inside your session, without a bash loop:

1. You start a loop once with /ralph-loop and a task.
2. Claude works on the task and at some point tries to stop.
3. A Stop hook intercepts that moment and hands it the same task again.
4. Claude sees its own earlier work: the changed files and the git history. If the tests failed, it sees that too.
5. This repeats until Claude outputs the agreed completion text, or the maximum number of rounds is reached.

# Start a loop (inside a Claude Code session)
/ralph-loop "[task description]" --completion-promise "COMPLETE" --max-iterations 30

# Stop early
/cancel-ralph

--completion-promise sets the text Claude must output as <promise>COMPLETE</promise> once the work is done. The plugin matches that text exactly, so you can't pack several conditions into it. --max-iterations defaults to unlimited. Without that limit, an impossible task loops forever, and every round costs tokens. So always set it.

A prompt that can survive a loop

With Ralph, the prompt is the only steering wheel. Nobody is watching to correct course, so anything vague gets filled in by Claude, thirty times over.

Too vague:

"Build a todo API and make it good."

Testable:

Build a REST API for todos. Done when:
- All CRUD endpoints work (GET, POST, PUT, DELETE)
- All endpoints validate their input
- Tests pass (coverage > 80%)
- There is a README with API documentation

Output <promise>COMPLETE</promise> when all criteria are met.

Too big:

"Build a complete e-commerce platform."

Phased:

Phase 1: User authentication (JWT, registration, login, tests)
Phase 2: Product catalogue (list, search, detail, tests)
Phase 3: Shopping cart (add, remove, checkout, tests)

Work phase by phase. Don't start phase 2 until phase 1 is fully done.
Output <promise>COMPLETE</promise> when all three phases are done.

In the good versions, Claude can determine for itself whether it is finished. That is exactly what the completion text needs.

When Ralph doesn't work

The plugin documentation lists the cases where you'd better not use it: tasks that need human judgement or design decisions, one-off operations, tasks without a clear success criterion, and debugging in production. Huntley is careful too. He sees the technique mainly for new projects, expects it to get you roughly 90% of the way, and writes that the result is only as good as whoever drives the loop: "LLMs are mirrors of operator skill".

Putting it together: an unattended session

To keep the session running when you close the terminal or drop your SSH connection, run Claude inside tmux. tmux keeps the terminal session alive on the machine it runs on, independent of your connection. That does need to be a machine that stays on, such as a server or a desktop. Close the lid of the laptop that tmux itself runs on, and everything goes to sleep with it.

# 1. Go to your project (with CLAUDE.md and deny rules)
cd ~/projects/my-app

# 2. Start a tmux session
tmux new -s ralph-work

# 3. Start Claude in auto mode
claude --permission-mode auto

# 4. Inside Claude: start the loop
/ralph-loop "Finish the auth module. Done when: JWT login, registration and refresh tokens work, password reset by email works, tests pass (coverage > 80%) and the conventions in CLAUDE.md are followed. Output <promise>COMPLETE</promise> when everything is done and tested." --completion-promise "COMPLETE" --max-iterations 30

# 5. Detach: Ctrl+B, then D

# 6. Come back later
tmux attach -t ralph-work

You don't need a log file via | tee here, and it doesn't work well with an interactive terminal interface anyway. Claude Code keeps every session as a transcript on your own machine (under ~/.claude/projects/), and the git history shows what changed in each round.

What does it deliver?

The plugin's README lists three results: six repositories in one night during a Y Combinator hackathon, a 50,000-dollar contract delivered for 297 dollars in API costs, and a complete programming language ("cursed") built over three months. These are claims by the people behind it, not independently checked. The contract example comes from a screenshot Huntley shared, and it used a different coding agent (Amp), not Claude Code.

Five rules for a night without supervision

1. Make the task testable. Measurable criteria, ideally as tests Claude can run itself.
2. Put prohibitions in the settings, not only in CLAUDE.md.
3. Always set --max-iterations. By default there is no limit.
4. Use bypass only in a container. On your own machine, auto mode is the sensible choice.
5. Review everything before it goes to production. Claude is powerful, but not infallible.

Writing a good prompt is half the job. The other half is deciding up front what Claude may not do, and reading afterwards what it did. The loop keeps working through the night, but the judgement stays with you.

Sources

• Claude Code docs: Choose a permission mode
• Claude Code docs: Configure permissions
• Claude Code docs: How Claude remembers your project
• GitHub: ralph-wiggum plugin in anthropics/claude-code
• Claude plugins: Ralph Loop
• Geoffrey Huntley: Ralph (July 2025)