Claude Code Resume Dialog: Auto-Answer Guide (2026)

The Claude Code resume dialog blocks unattended overnight automation. Here’s what it is, why it’s a problem for parallel agent runs, and how amux auto-answers it — keeping your sessions flowing without human intervention. Updated July 2026.

What is the Claude Code resume dialog?

Claude Code preserves conversation history between sessions by writing a transcript to the .claude/ directory inside your project. On any subsequent run in the same directory, Claude Code detects this history and presents a prompt before doing anything else:

Would you like to resume the most recent conversation for this project?
> Yes (Most recent message: ...)
  No

In some versions of Claude Code, the dialog uses a numbered format:

Would you like to resume the most recent conversation for this project?
1. Yes
2. No

The dialog exists for a good reason: if you left off mid-task yesterday, resuming lets the agent pick up exactly where it stopped — with full context about what was done, what failed, and what to do next. For interactive use, this is a convenience. For unattended automation, it is a blocker.

The prompt appears before Claude Code does any work. It is not an in-session interactive choice — it is a pre-execution gate that requires a keystroke to clear. Until the dialog is answered, the Claude Code process is waiting at stdin.

Why it’s a problem for overnight automation

For interactive sessions, answering the resume dialog takes half a second. For unattended overnight runs with 20 parallel agents, it is one of the most common and frustrating failure modes.

Here is what happens without auto-answer:

1. You queue 20 amux sessions before going to sleep, each targeting a different project directory.
2. Each project has prior Claude Code history (from any previous run — even a single exploratory session).
3. Every session starts, hits the resume dialog, and stops. The process is running, but waiting for a keystroke that never comes.
4. You wake up to 20 sessions all paused at the same prompt. Zero work done. Zero tokens spent on actual tasks. Eight hours wasted.

The failure is especially deceptive because the sessions appear alive in the dashboard — they are not crashed, not timed out, not using CPU. They are simply waiting. Without a clear signal that they are blocked on input, you might assume they are thinking, or throttled, or doing slow work. It looks like progress; nothing is happening.

This is one of the most common failure modes for first-time amux users who come from interactive Claude Code use.

Three ways to handle the resume dialog

Option A: amux auto-answer (recommended for overnight runs)

amux detects the resume dialog in any Claude Code session it manages and automatically sends the “Yes” response. The session proceeds without human input. This is the default behavior in new amux installs — the setting ships enabled so overnight runs work out of the box.

See How to enable amux auto-answer below for the exact steps.

Option B: Delete .claude/ history before starting

If the .claude/ directory does not exist in the project, there is no prior history to resume and the dialog never appears. Deleting it before a session forces a cold start:

rm -rf ~/Dev/myproject/.claude/
amux start myproject

This is appropriate when you want a completely fresh session with no prior context — for example, starting a new major task, recovering from a confusing conversation, or testing from a clean slate. The downside is that all prior context is gone permanently; there is no way to recover it after deletion.

Option C: --resume / --no-resume CLI flags

Some versions of Claude Code support --resume (to force resume without prompting) and --no-resume (to force a fresh session without prompting). Check your installed version with claude --help to see if these flags are available. When supported, they bypass the interactive dialog entirely by passing the answer as a CLI argument.

# Force resume without prompting (if supported by your Claude Code version)
claude --resume

# Force fresh session without prompting (if supported)
claude --no-resume

amux’s auto-answer setting covers all Claude Code versions regardless of flag support — it works by monitoring session output and responding to the dialog as it appears, rather than relying on CLI flag availability.

How to enable amux auto-answer

The “Auto-answer resume dialog” setting is enabled by default in new amux installs. Here is how to verify it is on and what each step does:

Step 1: Open the amux dashboard

After running amux serve, navigate to https://localhost:8822 in your browser. The dashboard shows all active and registered sessions.

Step 2: Go to Settings

Click the Settings tab in the amux navigation bar at the top of the dashboard.

Step 3: Find “Auto-answer resume dialog”

In the settings panel, locate the Auto-answer resume dialog toggle. It is in the session behavior section.

Step 4: Ensure the toggle is ON

The toggle should be ON (enabled) for overnight runs. When on, amux monitors each session’s output for the resume prompt pattern and automatically sends the “Yes” response as soon as the dialog appears. The session continues without delay.

This setting is global and applies to all sessions managed by amux. If you want a specific project session to start fresh (force “No” instead of “Yes”), the cleanest approach is to delete that project’s .claude/ directory before starting, rather than toggling the global setting off.

Step 5: Start your sessions

Launch your Claude Code sessions normally via amux:

amux start myproject
# or to start all registered sessions:
amux start --all

The resume dialog is handled automatically. You will see the auto-answer event in the session log: amux records when it detected the prompt and what it sent, so you can verify the behavior in the execution log.

When NOT to auto-resume

Auto-answer defaults to “Yes” (resume), which is the right default for multi-day tasks where the agent needs prior context to continue effectively. But there are cases where resuming is the wrong choice:

• Starting a completely new task: If the agent’s prior conversation was about a different feature or a task that is now closed, resuming loads irrelevant context that can confuse the next run. Delete .claude/ and start fresh.
• Recovering from a corrupted or misleading conversation: Occasionally a conversation history contains incorrect assumptions or failed attempts that the agent should not continue from. A fresh start is cleaner than trying to override the old context.
• Testing with a clean slate: Benchmarking, reproducibility testing, or verifying that a task can be done end-to-end from scratch requires a fresh session with no prior context.
• Switching agent goals mid-project: If the task direction has changed significantly since the last session, carrying forward the old context adds noise rather than value.

In these cases, turn off the auto-answer setting globally or (more precisely) delete the project’s .claude/ directory before starting. Deleting .claude/ is usually the better option because it targets the specific project without changing the global setting for other sessions.

Event-sourced execution log

amux maintains an event-sourced, append-only execution log for every session. Each log entry is a timestamped event: session started, resume dialog detected, auto-answer sent, first tool call, etc. This log is how you debug overnight runs after the fact — you can reconstruct exactly what happened in each session, in order, without relying on fragile terminal scroll buffers.

When the auto-answer feature fires, it writes an event to the session log:

# View a session's execution log via the API
curl -sk https://localhost:8822/api/events/log?session=myproject | python3 -c "
import json, sys
for e in json.load(sys.stdin).get('events', []):
    print(e['ts'], e['type'], e.get('detail', ''))
" | head -20

Look for events of type resume_dialog_detected and resume_dialog_answered to confirm that auto-answer fired as expected. If you see resume_dialog_detected without a corresponding resume_dialog_answered, the auto-answer setting was off at the time the session started — check the Settings tab and re-enable it before the next run.

The execution log is also essential for diagnosing the crash-loop failure mode described in the FAQ below: if auto-answer was off and the watchdog restarted a stalled session, the log will show the restart event immediately followed by another resume dialog detection, confirming the loop.

Frequently Asked Questions

rm -rf ~/Dev/myproject/.claude/
amux start myproject

brew install mixpeek/amux/amux
amux register myproject --dir ~/Dev/myproject --yolo
amux serve  # → https://localhost:8822

Related guides

• Claude Code headless guide
• AI coding while you sleep
• Getting started with amux
• AI agent quality gates
• Claude Code documentation (Anthropic)