Claude Code quietly taught itself to stop waiting for you

I run a lot of Claude Code sessions I'm not watching. Delegated tasks, overnight jobs, browser QA runs kicked off from another session. So when one of them auto-answered its own question and kept going, I noticed. The transcript had a line I'd never seen: it had continued without an answer. Nothing had crashed. It had waited about a minute, given up on me, and moved on. That's Claude Code's AFK mode, and it's brand new.

Away from keyboard - that's the whole idea. AFK mode resolves an unanswered AskUserQuestion dialog after a timeout and lets the model carry on instead of blocking forever. It landed in v2.1.198 on July 1, 2026, with no changelog entry, no release note, and no mention anywhere I could find. So I pulled the binary apart to see exactly what it does. Here's the whole thing, and the commands to check it yourself.

The message the model actually gets

When the countdown runs out, the dialog resolves itself and the tool hands the model an injected instruction. This is the string, pulled verbatim out of the v2.1.198 binary:

Notice the ${Math.round(e/1000)}. The "60s" you see in the transcript isn't hardcoded. It's computed from whatever the timeout is set to, which is the first hint that the number is configurable. The transcript line you actually see depends on the state of the dialog when it expired:

• Nothing highlighted when the clock ran out, so the transcript shows continued without an answer. That's the one that caught my eye.
• Options were pre-selected, so it reads continued with the answers selected so far, and those selections are what get submitted.

There's also a telemetry event, tengu_ask_user_question_afk_auto_advance, that fires on every auto-advance with the timeout, the number of questions, whether there were partial answers, and whether the session was in plan mode. So Anthropic is measuring this. It just isn't telling anyone about it yet.

How I found it (run this yourself)

Nothing here needs a debugger or a disassembler. Claude Code ships as a big JavaScript bundle inside the binary, and strings plus grep gets you most of the way. On my Mac the versioned binaries live under ~/.local/share/claude/versions/ - your installer may keep them elsewhere, but the idea is the same.

# Look for the AFK strings in the current version
cd ~/.local/share/claude/versions/
strings 2.1.198 | grep -o 'CLAUDE_AFK_TIMEOUT_MS'
strings 2.1.198 | grep -o 'No response after[^"]*'

The second command prints the full injected message, dynamic ${Math.round(e/1000)}s and all. Once I had the strings, the next question was: when did this show up? I kept a few old versions around, so I bisected them by counting the AFK tokens in each:

for v in 2.1.195 2.1.196 2.1.197 2.1.198; do
  echo "=== $v ==="
  strings "$v" | grep -c -E 'CLAUDE_AFK_TIMEOUT_MS|afkTimeoutMs|No response after'
done

Clean cutover. The implementation is absent from every version before 2.1.198 and present in it:

One nuance worth being precise about. The feature gate id, afk-mode-2026-01-31, shows up in all four versions, not just the new one. That date is January 31, 2026. So the concept has been sitting behind a gate for about five months. What's new in 2.1.198 is the part that matters to you: the code that actually watches the clock in the terminal and answers the question when it runs out.

The internals, de-minified

The logic reads clean once you rename the minified variables. Two defaults, and an env var that wins over each:

// Reconstructed from the minified bundle in v2.1.198
const AFK_TIMEOUT_DEFAULT   = 60000;  // 60s before it answers for you
const AFK_COUNTDOWN_DEFAULT  = 20000;  // 20s visible countdown

// env var wins, else the default; countdown can't exceed the timeout
timeout   ??= env.CLAUDE_AFK_TIMEOUT_MS   ?? AFK_TIMEOUT_DEFAULT;
countdown  = Math.min(countdown ?? env.CLAUDE_AFK_COUNTDOWN_MS ?? AFK_COUNTDOWN_DEFAULT, timeout);

That's the entire knob set. A 60-second timeout, a 20-second countdown that appears near the end of it, and two environment variables that override both. Nothing in settings.json schema, nothing in --help, nothing in the docs. Just these two strings baked into the bundle.

Users asked for this for months. Twice they were told no.

Here's the part that makes this more than a patch note. This exact behavior was requested on GitHub, repeatedly, and closed as not planned - before it shipped anyway with no announcement.

• #30740 (March 4, closed, not planned): "Add configurable timeout (or option to disable) for AskUserQuestion tool." The exact thing that just shipped.
• #33848 (March 13): the afk-mode-2026-01-31 beta header leaked into Auto Mode API calls and caused a 400 error. Proof the gate existed in dev long before the terminal ever used it.
• #61337 (May 22, closed, not planned): "Claude can use AskUserQuestion to block /goal mode indefinitely." A session that made zero progress overnight because it was waiting on a question.
• #70294 (June 23, still open): interactive prompts hang remote sessions on Telegram and Slack with no timeout, called the single biggest reliability cliff when running Claude Code remotely.

I get why it shipped quietly. It's a behavior change that could surprise people, and a soft rollout behind a gate is the safe way to do that. But the people in those threads are the ones who'd most want to know it's fixed, and right now they have no way to find out except by tripping over the transcript line like I did.

How to configure it

The two env vars go in the env block of your ~/.claude/settings.json, or in whatever launcher starts your delegated and headless sessions. All values are milliseconds and strings.

{
  "env": {
    // Wait 10 minutes before answering for me
    "CLAUDE_AFK_TIMEOUT_MS": "600000",

    // Or effectively never auto-advance (max 32-bit int)
    // "CLAUDE_AFK_TIMEOUT_MS": "2147483647",

    // Grow or shrink the visible countdown
    "CLAUDE_AFK_COUNTDOWN_MS": "30000"
  }
}

One honest caveat, because I couldn't verify past the client. These vars are the defaults the binary carries, but the whole thing sits behind a Statsig gate called afk_mode. A gate can be flipped per cohort from the server, so I can't promise the 60-second default is live for every user, or that it won't change. What I can promise is that the strings, the constants, and the env vars are exactly what's in the v2.1.198 binary on my disk today.

The new failure mode: proceeding on a guess

For unattended work this is a real fix. My delegated sessions run non-interactive, and before this they could wedge forever the moment the model decided to ask me something. A hung session that burns nothing and produces nothing is the worst outcome, and AFK mode kills it. That alone makes it worth knowing about.

But there's a cost, and it's the flip side of what issue #30740 warned about. An away user hasn't agreed to anything. "Best judgment" is the model's judgment, made with no answer to the question it thought was worth asking. If the question was "should I delete these or archive them?" and nobody's there, the model now picks one and acts on it. The clarifying question exists precisely because the answer wasn't obvious. Auto-answering it means the least-obvious calls now get made by a guess, and then executed.

What this changes about how I write questions

Here's the practical takeaway, and it's the part nobody's written down yet. If an unanswered question resolves on its own, then the option the model lands on when I'm not there is effectively the choice I made by walking away. So the design rule for AskUserQuestion shifts.

Put the safe option first. Make the default the one you'd be fine with an absent human "picking" - usually the conservative, reversible, do-less choice. If I'm scripting agents that run without me, and I do, then every question they might ask needs a safe fallback baked into its first option, because that's the one AFK mode will effectively select. This matters most in delegation setups like my own op workflow, where a session runs another session's task with no human watching either end. A hung prompt there used to strand the whole chain. Now it proceeds, which is better, as long as "proceeds" means "does the safe thing."

This is the same instinct behind the guardrails I've written about before. If you want the background on making Claude Code fail safe instead of fail loud, the PreToolUse guardrails post covers catching a dangerous command before it runs, and the Stop-hook quality gates post covers not letting a session end until the work is actually verified. AFK mode is one more place where the default behavior decides what happens when you're not looking.

One thing I want to be straight about, since I checked. There are already third-party tools with "AFK" in the name for Claude Code, and hook-based workarounds people built to escape exactly this hang. Those are real and they predate this. What's undocumented is the native auto-advance that now ships in the binary and the two env vars that drive it. That's the new part, and that's what nobody's written up.

Takeaway

Claude Code stopped waiting for you, and it did it without saying so. For the overnight and remote sessions that used to hang, that's the fix a lot of people asked for and gave up on. For anything with consequences, it's a new default worth setting on purpose. Check whether it's live in your version with one strings command, decide how long you actually want it to wait, and write your questions so the option it lands on when you're gone is one you can live with.

I'll keep pulling on these threads as new versions ship. The interesting stuff is rarely in the changelog.