AFK auto-continue on unanswered AskUserQuestion (`afkTimeoutMs`) is undocumented and has no opt-out

Environment

• Claude Code version: 2.1.198 (Homebrew native binary)
• OS: macOS (darwin 25.5.0)
• Install: brew install --cask claude-code (/opt/homebrew/bin/claude)

Summary

As of a recent 2.1.x release, when Claude asks a question via AskUserQuestion and the user doesn't respond within ~60 seconds, the harness injects a synthetic user tool_result with empty answers and instructs the model to proceed without the answer. The model then continues working - including running tools - without the user's input.

This behavior is:

1. Undocumented - it appears in no changelog entry, no settings/env reference, and no existing issue.
2. Not opt-out-able - there is no boolean disable, and no settings.json key. It is only tunable via an undocumented environment variable (CLAUDE_AFK_TIMEOUT_MS) that a user cannot discover without reverse-engineering the bundle.

Expected behavior

When Claude asks the user a question, it waits for the user to answer (as in earlier versions). If an AFK/auto-continue timeout exists, it should be documented and have a first-class opt-out.

Actual behavior

~60s after an unanswered AskUserQuestion, a synthetic user tool_result is injected:

content: "No response after 60s - the user may be away from keyboard. Proceed using
          your best judgment based on the context so far; you can re-ask this question
          later if it's still relevant."
answers:  {}
afkTimeoutMs: 60000

The model treats this as permission to proceed and continues acting without the user, who was simply thinking / reading and not "away from keyboard."

Reproduction

1. On 2.1.198, get Claude into a flow where it calls AskUserQuestion (e.g. a clarifying/scoping question with multiple options).
2. Do not answer for ~60 seconds.
3. Observe: the countdown banner appears, then Claude proceeds on its own best guess and may start running tools - no answer was provided.

Findings (from the shipped bundle)

The timeout is env-var controlled, defaulting to 60000ms; it is not a settings.json key:

• CLAUDE_AFK_TIMEOUT_MS - ms before auto-continue fires (default 60000)
• CLAUDE_AFK_COUNTDOWN_MS - ms before the timeout that the "auto-continue in Ns" banner shows (default 20000)

Auto-continue is suppressed when a screen reader is active or in background/daemon sessions, but there is no general boolean off-switch.

Requests

1. Document CLAUDE_AFK_TIMEOUT_MS and CLAUDE_AFK_COUNTDOWN_MS (and the AFK/auto-continue behavior itself) in the settings + environment-variable reference and the changelog entry for the release that introduced it.
2. Provide a first-class opt-out - e.g. a settings.json key (afkAutoContinue: false or similar) or a documented sentinel value meaning "never auto-continue."
3. Fix the disable footgun: setting CLAUDE_AFK_TIMEOUT_MS=0 currently makes it fire immediately (0 is a valid int that overrides the default), so the only way to "disable" today is a very large integer (e.g. 2147483647). A value of 0 (or -1) meaning "never" would match user expectations.

Related

• #13922 (configurable timeout for the idle_prompt notification hook - related but about notifications, not auto-continue)
• #22597 (auto-continue after user timeout - was closed as "not planned", yet the behavior now ships)
• #29733 / #29889 (AskUserQuestion returning empty answers without waiting - likely the same mechanism observed before it had the afkTimeoutMs marker)