Let Claude Code Work Autonomously: The Complete Guide

Imagine giving Claude Code a complex task, closing your laptop, going to sleep — and waking up the next morning to a fully working codebase. No pauses, no questions, no half-finished work. That's exactly what becomes possible when you combine AFK mode with the Ralph Wiggum plugin. Two techniques that together turn Claude Code into a fully autonomous development assistant.

In this article I'll explain what both techniques are, how they work, why they're so powerful — and how you can start using them today.

The problem: Claude stops too often

By default, Claude Code has two behaviors that make AFK usage impossible:

It constantly asks for permission. Want to modify a file? Pause. Run a command? Pause. You come back and Claude has been waiting for an hour for you to press Enter.
It stops too early. Claude thinks it's done, but the tests are still failing, the code still has bugs, or the task is only half complete. It stops and waits for a new instruction from you.

The combination of these two problems makes it practically impossible to let Claude work unattended. Until now.

Solution 1 — AFK mode: Claude that doesn't pause

AFK stands for Away From Keyboard. AFK mode ensures that Claude doesn't ask for permission before taking actions and simply keeps going without waiting for you. You achieve this with three tools working together.

The flag: --dangerously-skip-permissions

This is the most important setting for AFK usage. The name sounds scary — and that's intentional. It tells you that you're trusting Claude with your files, without your involvement. Claude can create, modify, or delete files without asking.

Always use this within a scoped project directory, never as root, and never on a system with sensitive production data.

# Basic usage — Claude asks nothing, just keeps working
claude --dangerously-skip-permissions "finish building the login module"

# With logging — save everything Claude does
claude --dangerously-skip-permissions "write unit tests" | tee claude-output.log

tmux — so your session stays alive

Even with the right flags, everything stops if you close your laptop or disconnect. tmux is the solution. It's a program that "detaches" your terminal session from you — the session keeps running in the background, even after you disconnect. Think of it as a room where the lights stay on, even after you've left.

# Step 1 — Start a new named session
tmux new -s claude-session

# Step 2 — Start Claude inside that session
claude --dangerously-skip-permissions "finish building the dashboard component"

# Step 3 — Detach: Ctrl+B, then D
# Claude keeps working in the background

# Step 4 — Come back later
tmux attach -t claude-session

CLAUDE.md — Claude's instruction manual

The more Claude knows about your project, the less it gets stuck on ambiguities. A CLAUDE.md file in the root of your project is an instruction document that Claude automatically reads at the start of every session. Think of it as a briefing you'd give a new colleague: what is it allowed to do, what not, how does the project work, and what are the conventions?

# CLAUDE.md — Project instructions for Claude

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

## What Claude may do independently
- Create and modify files in /app and /resources
- Install Composer packages
- Create migrations

## What Claude may NOT do
- Modify .env
- Drop or truncate the database
- Push code to git

Solution 2 — Ralph Wiggum: Claude that doesn't stop

AFK mode ensures Claude doesn't pause for permission. But the second problem remains: Claude stops too early. The Ralph Wiggum plugin solves this by creating a self-repeating loop. Claude works on a task, tries to stop — but is automatically sent back to keep going, until the task is truly complete.

Why is it called "Ralph Wiggum"?

Ralph Wiggum is a character from The Simpsons, known for his cheerful persistence despite setbacks. The technique was invented by developer Geoffrey Huntley, who described it as: "Ralph is a Bash loop" — a simple while true that repeatedly feeds an AI the same prompt until the work is done.

How does the loop work?

The principle is as simple as it is brilliant:

You give a task once via /ralph-loop
Claude works on the task
Claude tries to stop
The Stop Hook intercepts that and feeds the same prompt back
Claude sees its own previous work (files + git history) and improves it
Repeat until the task is done — then the loop stops automatically

The clever part is the Stop Hook — a script that intercepts the exact moment Claude wants to end the session. Instead of stopping, the hook sends Claude back to the beginning with the same prompt. But Claude isn't blind: it sees the files that were already created and the git history from previous iterations. Each round it's smarter than the last.

The commands

# Start a loop
/ralph-loop "[your task description]" \
  --completion-promise "COMPLETE" \
  --max-iterations 50

# Cancel the loop if you want to stop early
/cancel-ralph

The --completion-promise parameter is the exact text Claude must output when the task is done. The --max-iterations parameter stops the loop after at most N attempts — this is your safety net for impossible tasks. Always set this.

How do you write a good prompt?

This is the most critical skill when using Ralph. A vague prompt leads to a vague outcome — or an infinite loop. Compare these examples:

❌ Bad — too vague:

"Build a todo API and make it good."

✅ Good — clear and measurable:

Build a REST API for todos. When complete:
- All CRUD endpoints working (GET, POST, PUT, DELETE)
- Input validation present on all endpoints
- Tests passing (coverage > 80%)
- README with API documentation included

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

❌ Bad — too much at once:

"Build a complete e-commerce platform."

✅ Good — phased approach:

Phase 1: User authentication (JWT, registration, login, tests)
Phase 2: Product catalog (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 complete.
Output <promise>COMPLETE</promise> when all three phases are done.

The combination: AFK + Ralph = fully autonomous

Separately, AFK mode and Ralph Wiggum are already powerful. Together, they're extraordinary. They each solve a different problem and reinforce each other perfectly:

AFK mode ensures Claude doesn't pause for permission
Ralph Wiggum ensures Claude doesn't stop until the task is truly done
tmux ensures the session stays alive even when you're away
CLAUDE.md ensures Claude knows the context and conventions

This is the complete workflow for a fully unattended Claude session:

# Step 1 — Go to your project directory (make sure CLAUDE.md is present)
cd ~/projects/my-app

# Step 2 — Start a tmux session so everything keeps running
tmux new -s ralph-work

# Step 3 — Start Claude with AFK flag + Ralph loop + logging
claude --dangerously-skip-permissions \
  '/ralph-loop "Build the complete auth module.
  Requirements:
  - JWT authentication (login, registration, refresh token)
  - Password reset via email
  - Tests with coverage > 80%
  - Follow conventions in CLAUDE.md
  Output <promise>COMPLETE</promise> when everything is done and tested."
  --completion-promise "COMPLETE"
  --max-iterations 30' | tee claude-output.log

# Step 4 — Detach and walk away (Ctrl+B → D)

# Step 5 — Later: check what was done
tmux attach -t ralph-work

You set it up once, walk away, and Claude works on the task — asks for no permissions — keeps improving and repeating — and stops automatically when it's done.

Proven results

Ralph Wiggum isn't just theory. The technique has been extensively tested in real production situations:

6 repositories generated in a single night during a Y Combinator hackathon
A $50,000 contract completed for just $297 in API costs
A complete programming language ("cursed") built over 3 months using iterative loops

The golden rules

Be as specific as possible in your task description. Vagueness leads to stalling or wrong assumptions. Give Claude measurable success criteria.
Always use a CLAUDE.md. Without context, Claude makes assumptions you may not want. With CLAUDE.md, it works within your boundaries.
Always set --max-iterations. Even the best prompts can lead to an infinite loop if the task turns out to be impossible. Max-iterations is your safety net.
Always log what Claude does. Use | tee output.log so you can read exactly what happened, even if you weren't there.
Review the work when you come back. Claude is powerful, but not infallible. Always review the code it wrote before deploying or pushing.

Conclusion

The combination of AFK mode and the Ralph Wiggum plugin marks a shift in how you work with Claude Code. No longer an assistant that demands your attention, but an autonomous developer that keeps working as long as there's work to be done. Whether you want a feature built while you sleep, or a large refactor done while you're in meetings: with this setup you give the instruction once, and Claude takes care of the rest.

The only skill that matters? Writing a good prompt. The loop handles everything else.