[BUG] AskUserQuestion still auto-continues after 200s with askUserQuestionTimeout "never": CLAUDE_AFK_TIMEOUT_MS=200000 appears in process env (follow-up to #78125)

What's wrong

Questions from AskUserQuestion still answer themselves after exactly 200 seconds, even though askUserQuestionTimeout is set to "never":

● Claude asked:
[...]
● No response after 200s — continued without an answer

This continues #78125, which I filed in July. It was closed as stale with no reply, so I'm opening a new one with more evidence.

My ~/.claude/settings.json has "askUserQuestionTimeout": "never" at the top level, and /config shows "Question auto-continue timeout: never". No managed, project or local settings file overrides it.

Evidence

1. It still happens on recent versions. My session transcripts have 7 AskUserQuestion results with "afkTimeoutMs":200000, between 17 Sept and 7 Oct 2026, on versions 2.1.274, 2.1.276 and 2.1.283, across three different projects. All seven are exactly 200000 ms. That is not one of the values the setting accepts (60s, 5m, 10m, never).

2. Only the env var can produce 200s. In the shipped bundle (I checked 2.1.283 and 2.1.292), the AFK hook reads:

timeoutMs = env.CLAUDE_AFK_TIMEOUT_MS ?? timeoutMs ?? 60000

and the question dialog only turns the timer on when:

!screenReader && !hasExternalRacer && !<...>() &&
  (settingTimeout !== null || env.CLAUDE_AFK_TIMEOUT_MS !== undefined)

With the setting at "never", settingTimeout is null, so the timer can only run if CLAUDE_AFK_TIMEOUT_MS is defined.

3. Claude Code sets CLAUDE_AFK_TIMEOUT_MS=200000 in its own environment after startup. For the affected session (a claude -r process on 2.1.283, running in tmux since 28 Sept):

• /proc/<claude pid>/environ (the environment it started with) has no CLAUDE_AFK_TIMEOUT_MS.
• A Bash tool shell that this process started has CLAUDE_AFK_TIMEOUT_MS=200000 in its environment.
• The variable isn't in my shell profile, the tmux environment (global or per session), any settings*.json (user, project or local), ~/.claude.json, plugins, settings backups or shell snapshots. No managed settings exist under /etc/claude-code.

So something inside Claude Code puts CLAUDE_AFK_TIMEOUT_MS=200000 into process.env after startup, and that silently overrides askUserQuestionTimeout: "never". My guess is a remotely delivered setting or feature flag, but I couldn't confirm that from the client.

A fresh session on 2.1.292 doesn't have the variable right now, so whatever sets it may come and go, or it may only reach long-running sessions.

What should happen

• With askUserQuestionTimeout: "never", a question never answers itself.
• Claude Code should never set CLAUDE_AFK_TIMEOUT_MS itself. If it gets the value from somewhere remote, it should be visible and the user setting should win.
• When the AFK path fires, the model gets "Proceed using your best judgment", and in practice it picks the "(Recommended)" option. So silence turns into approval, which is the problem #73772, #88790 and #90407 describe.

Steps to reproduce

I can't reliably reproduce the variable getting set. When it is set:

1. Set "askUserQuestionTimeout": "never".
2. Run a long-lived session in tmux and switch to other panes or sessions.
3. Claude asks a question with AskUserQuestion. Don't answer.
4. After 200s, the question resolves with "No response after 200s" and Claude carries on.

To check whether a session is affected, ask Claude to run env | grep CLAUDE_AFK in it.

Environment

• Claude Code 2.1.274 to 2.1.283 (affected); 2.1.292 installed now
• Windows 11, WSL2 (Linux 6.6), Windows Terminal, tmux
• Permission mode: auto
• Native install (~/.local/share/claude/versions/)

Related

• #78125: same bug, closed as stale without a reply
• #62657, #73105, #73528: the 60s timer, made opt-in in 2.1.200
• #77602: questions answering themselves with the setting unset, in Remote Control sessions
• #88790, #90407: an answer reported as chosen when nobody chose it