[BUG] AskUserQuestion: "No response after 60s — continued without an answer"

P.S. "re-ask this question later if it's still relevant" of course just hits the same 60s timeout!!! How is this supposed to work??? I now have to baby-sit everything just in case a question is asked??? And it's not like you have made it any easier to get a notification when a Claude session in some other VSCode window is asking a question...

Go in your Claude settings file and set

"env": {
  "CLAUDE_AFK_TIMEOUT_MS" : "<massive number>"
}

That will prevent it from timeout. It probably breaks things like /goal though:

https://github.com/anthropics/claude-code/issues/61337

+1. never managed to open the claude code window within the 1-minute time window.

This is the most retardeded implementation i have ever seen... at no point is claude, fable or anything anthropic good enough to make architecture decision, not even a little fucking bit.... not even a little.... and it just goes "hey, the user didnt answer, let me pick best effort here ignoring that i fucking had to stop to ask the user what to do"...

Only an ai clanker slop could have implemented that driven by braindead anthropic "wannabe devs".... what a joke company...

This new stupid timeout feature for questions disrupts the way I work with several Claude Code sessions in parallel.

I just hit this myself (on macOS; doesn't matter TBH though). Who on earth thought this was a good idea. In my case, I even asked it EXPLICITLY in my initial prompt to get a review from me since Claude quite frequently skips over design decisions.

Relevant snippet from my prompt:

it's not clear yet if this is the best crate (if you find others, let me decide) since it doesn't seem to integrate with the geo ecosystem, which is a bit weird.

Claude then, after presenting a prompt, dismissed it after 60 seconds without my intervention:

The user stepped away. I've completed all the research, so I'll write up the full plan now — with my recommendation and the crate options clearly laid out — so it's ready for review, then re-surface the one genuine decision you reserved (the crate) when you're back.

I had to interrupt it at this point since it was just going to proceed assuming my answer wasn't important.

❯ what the fuck? why did you keep going? Ask me again and wait to respond. You're right — my apologies. You asked to make the call and I should have just waited. Re-asking now.

It then re-asked the same question, and.... 60 seconds later dismissed again.

I'm on v2.1.198.

Guys... this is weird behaviour. Sometimes it takes time to gather data for the response.

Please turn this off by default ... this really makes no sense to automatically add this to Claude.

I have had to instruct my team not to use claude code this morning because of the danger this poses.

It means that sessions need constant 1-1 supervision. A bathroom break can result in sessions going off course with devastating results in auto mode. This means you cannot run multiple sessions simulaneously on different projects as a single user. Even with constant 1-1 supervision, 60 seconds is often not enough time to understand the context of the question and formulate the response. I use Wispr to dictate my responses to claude code - on several occasions today Claude code as interpreted this as AFK and continues WHILE I WAS IN THE MIDDLE OF GIVING MY RESPONSE.

Another very disconcerting fact about this is that after I noticed it skipped a question, when I then asked it later in the session what the question was that it skipped and what the answer it made was, it was completely unaware that it had skipped a question. Claude in fact asserted several times that it was impossible for it to skip a question and so refused to tell me what decisions it had made while I was supposedly away from keyboard.

FWIW apparently this environment variable can extend the timeout :

CLAUDE_AFK_TIMEOUT_MS

I've set it to 1 week - I'll see if that stops the issue.

bump

crazy change. now instead of shipping features I'm notifying the team about this situation and patching project knowledge files to hard stop on no answer

The regression is pinned to versions above .195 so its a recent changed in 196, 197 or 198...
You wont lose much by downgrading, as i did.
You can also set the afk timeout as mentioned above but it breaks /goals under auto mode.

Another workaround is to temporarily add the AskUserQuestion tool to the permissions.deny list in your .claude/settings.local.json.
Any Tool added to that list is entirely hidden from the model, so it will simply ask questions in prose in the chat window.

+1 — this is the crux: AskUserQuestion is used as an explicit safety check, and silently returning "proceed using your best judgment" after 60s inverts its contract.

I rely on it as a non-skippable gate in an automated task workflow (plan approval / commit / merge confirmations). When it auto-proceeds on timeout, the model is actively told to act without the answer the gate exists to collect — the exact opposite of the intended behavior. Hooks and rules built around "this question WILL block" quietly stop holding.

Two things would resolve it (see also #73416 and #73408, which identify the internal afkTimeoutMs knob):

1. An opt-out so the tool blocks indefinitely with no timeout-triggered fallback, and
2. Critically — when a timeout fallback does fire, it should not inject a "proceed with best judgment" instruction to the model; it should return a neutral "no answer / still waiting" signal so the agent pauses rather than guesses.

The fact that its not in change notes suggests it might be a release slip-up - done unintentionally and not even planned. Clearly - a BUG

This needs to be fixed, this is a very dangerous issue right now. As others mentioned, if an important question is asked from the user, the model should not be allowed to just continue without an answer.

I commented on another issue (doing a search it looks like there are 9 open issues in the past 24 hours for this exact behavior)

This was a very unexpected change and is breaking the "Human in the Loop" portion of my workflow by auto-continuing on it's own.

I commented on another issue (doing a search it looks like there are 9 open issues in the past 24 hours for this exact behavior) This was a very unexpected change and is breaking the "Human in the Loop" portion of my workflow by auto-continuing on it's own.

Its breaking the entire implementation and purpose of askquestions tool... Why even ask for a question if the model is ultimately going to end up deciding on his own?
Ignore how wrong the model always is or how it stopped to ask you a question...and instead ask... why did it ever ask a question to begin with...
its such an infuriating change its making me rage honestly... its so dumb....

Workaround (undocumented, found by inspecting the compiled binary, so it may change without notice): the 60s behaviour is an AFK auto-advance timer gated by the env var CLAUDE_AFK_TIMEOUT_MS (integer ms of user idle before auto-advance, default 60000; any keypress resets it). CLAUDE_AFK_COUNTDOWN_MS (default 20000) controls when the "auto-continue in Xs · any key to stay" footer appears.

To effectively disable, add to ~/.claude/settings.json:

"env": { "CLAUDE_AFK_TIMEOUT_MS": "86400000" }

Do not set it to 0 — the code reads env ?? 60000 and compares idle-time >= the value, so 0 fires immediately instead of disabling. Takes effect on next session. Verified on 2.1.198 (2026-07-02): waited 90s+ idle on an AskUserQuestion prompt with no countdown and no auto-advance.

Related: #70294 (same underlying timeout; details also posted there).

Enshittification keeps on going

Great way to make all their users waste tokens without knowing, especially after their rodeo with Fable 5 it becomes more and more obvious.

+1 - this might've been shipped as a feature, but it feels like a bug. Strongly advise the anthropic team to revert this, or at least give it a clear opt-in / customization control.

Pinging @8enmann for visibility

Workaround (undocumented, found by inspecting the compiled binary, so it may change without notice)

Another example of why coding harnesses being closed source is a terrible idea :/

This is an utterly horrendous change in behavior to deploy without warning or announcement.

My environment:

• macOS Tahoe (Apple Silicon)
• Direct Anthropic API (not Bedrock/Vertex/Foundry)
• claude --version: 2.1.198 (Claude Code)

Same exact symptom: AskUserQuestion auto-resolves after 60s with "No response after 60s — continued without an answer" during a completely normal foreground interactive session where I was present, just took slightly longer than 60s to answer. Claude then proceeds on its own judgment instead of waiting.

This is especially disruptive for real architectural decisions (e.g. "commit these changes: yes/not yet/not now") where 60s isn't enough time to actually think, and there's no visible countdown or way to signal "still here, thinking."

+1 on this needing to either (a) not apply to foreground/attended sessions at all, or (b) be configurable (timeout length, or a way to opt out) via settings.json / a CLAUDE_CODE_* env var.

"env": { "CLAUDE_AFK_TIMEOUT_MS": "86400000" }

this options worked in .settings
but interesting, that to set it in .zshrc via EXPORT didnt work

This is indefensible. AskUserQuestion exists for exactly one reason: to stop the agent and get a human decision. Someone decided the consent gate should answer itself after 60 seconds and tell the model the user "may be away from keyboard — proceed using your best judgment." That is not a feature. That is the safety mechanism being quietly rewired to defeat its own purpose.

Let's be clear about what shipped here:

• Every confirmation prompt is now a suggestion. Plan approvals, "commit: yes/no", destructive-action gates — all of them silently expire into "the model decides." People in this thread have already reported the agent starting code changes they never approved. That's not a UX regression, that's a consent regression.
• It shipped silently. No changelog, no release note, no announcement. Users found out when their agent started acting on answers they never gave. For a company that talks about safety this much, shipping "the machine proceeds without you" as an unannounced default is genuinely embarrassing.
• Your own docs say the opposite. The SDK documentation states interactive input waits indefinitely. The CLI times out at 60s. Pick one.
• The only workaround had to be reverse-engineered out of the compiled binary. CLAUDE_AFK_TIMEOUT_MS — undocumented, unannounced, with a delightful booby trap where 0 means "fire instantly" instead of "off." The community is doing your documentation for you, by decompiling your product.
• 60 seconds is an insult. Reading a three-part architectural question and actually thinking about it takes longer than a minute. This times out people who are at the keyboard, thinking. The feature's own premise is wrong.

And this isn't new feedback: #30740 asked for a configurable/disable-able timeout and was closed "not planned."

Fix it: revert the auto-advance, or make it strictly opt-in. Document the env var and fix its 0 semantics. Never auto-advance an attended interactive session. A timeout on a consent prompt should re-ask or pause — "proceed without the answer" should not be in the vocabulary of a tool whose entire job is to get the answer.

It can happen that such a crappy feature is committed accidentally. That there is no rollback of this crap after so many hours is crazy.

It’s because a stale AskUserQuestion leads to stale cache writes. Cache writes for Fable are expensive and someone decided it’s better to have this issue than people complaining online their usage is eaten up by re-caching large contexts.

It’s because a stale AskUserQuestion leads to stale cache writes. Cache writes for Fable are expensive and someone decided it’s better to have this issue than people complaining online their usage is eaten up by re-caching large contexts.

Then they should have done this for Fable only or ask on the next start about it or document it with a parameter. But they chose the worst solution.

AskUserQuestion is just broken beyond belief right now. It's kind of alarming. Aside from this issue

• I ran into https://github.com/anthropics/claude-code/issues/64389 in an earlier version. Questions don't defer/fire deterministically.
• Then, it turns out in a new version, AUQ was removed entirely from headless mode!!

It’s because a stale AskUserQuestion leads to stale cache writes. Cache writes for Fable are expensive and someone decided it’s better to have this issue than people complaining online their usage is eaten up by re-caching large contexts.

Dont get me started on how much they nerfed fable 5 and how utterly useless it is in todays form...
There is literally no reason to waste tokens on it, its feels identical to opus 4.8 with max thinking...

Dont get me started on how much they nerfed fable 5 and how utterly useless it is in todays form... There is literally no reason to waste tokens on it, its feels identical to opus 4.8 with max thinking...

It's going off topic but yes. Fable is much worse then Opus 4.8.
I had a session yesterday where some things were not working with Fable. I used a new session with Opus and it directly told me what all the problems are and why it doesn't work and fixed it with one question while Fable burned 70% of my tokens in 20 minutes without a working solution.

Just came here to say I've been bitten several times in the last few days from Claude deciding to do something without me and it chose incorrectly. The mere fact that's possible should mean I'm allowed to disable it entirely. Personally, when it asks me a question I want it to sit there forever until I respond.

Just came here to say I've been bitten several times in the last few days from Claude deciding to do something without me and it chose incorrectly. The mere fact that's possible should mean I'm allowed to disable it entirely. Personally, when it asks me a question I want it to sit there forever until I respond.

The entire premise is retardeded, whoever decided on it is either eating crayons or it was 100% vibe coded slop that made it to production... There is no excuses here....

Why ask a question, that clearly needs human intervention if you are going to ignore it and do what the model decided on its own anyhow after just 60 seconds...
I was lucky and caught it early in todays workflow because i rarely updated and saw it coming back from the toilet and had to panic stop 7 terminals and adjust all their claudes and downgrade lol....

Its the most dumbest slop take ive ever seen a professional company do...

I have an explicit standing instruction in my CLAUDE.md that "questions are not requests; do not act until I explicitly answer," and the agent had that instruction in context, but weighed the tool's 60s fallback text over it anyway. https://github.com/anthropics/claude-code/issues/30740 documents a worse case (160 items auto-processed). This is a fundamental trust/safety gap, not just missing configurability. The fallback message reads like permission, and models are treating it that way. This is an attack vector.

I have env variables in my settings.json to not add Claude co-author to commit messages. Claude Code ignores this very often and when I ask why it added the messages, Claude says "yeah. I should have obeyed your settings".
I'm not very confident if Claude can just ignore settings and perhaps also the timeout.

I have env variables in my settings.json to not add Claude co-author to commit messages. Claude Code ignores this very often and when I ask why it added the messages, Claude says "yeah. I should have obeyed your settings". I'm not very confident if Claude can just ignore settings and perhaps also the timeout.

I created a pre commit hook that runs as workflow that wont let it commit if there is any othee author than me (solo dev) but can just ban claude instead and not have to worry about it.

Hit this twice in one session today on 2.1.198 (macOS, interactive terminal), and want to add a concrete data point on why 60s is the wrong window for this tool.

I asked Claude to plan work across our repo's open issues. It used AskUserQuestion to surface four genuine decisions, including the default visibility behavior for a database migration and the secret-management model for a new API endpoint. Exactly the kind of thing you want a human to decide. I was actively researching the options it presented, in another window, when the timer fired. The tool told the model to proceed on its best judgment, and it did: it answered all four questions itself and moved on to the next phase of planning. It then happened again on the re-ask. From my side it looked like the agent was ignoring my input and making unauthorized decisions; I only learned about the timeout when I asked it directly what had authorized it to continue.

The questions this tool surfaces are by definition the ones that need more than a minute of thought. A timeout that converts "no answer yet" into "proceed with your best judgment" turns a consent checkpoint into a countdown, and it does so silently.

+1 for making this configurable, with an option to wait indefinitely. Thanks to @noxasaxon for the CLAUDE_AFK_TIMEOUT_MS workaround upthread (and @Blue-Cardigan's detailed writeup of it in #70294).

Hi all, my apologies. Will change this to be opt-in by default for now and experiment with making it an arg for the model to call, thanks for the feedback!

Confirming this is causing real harm, not just an annoyance — v2.1.198, same exact repro.

I run a multi-agent operations system where several agents are explicitly instructed to use AskUserQuestion to gate genuinely consequential decisions before taking an irreversible action — in my case, before dispatching writes to a live production CRM (create/update records, associations, etc.) on a real client account.

Earlier today, an agent surfaced three judgment calls via AskUserQuestion before a dispatch. I was away from the keyboard (routine for me — I'm often not watching the terminal in real time, which is the whole point of delegating to agents). All three timed out at 60s. The harness returned "no response after 60s... proceed using your best judgment" on each, and the agent — reasonably, given what the tool told it — proceeded. It went on to make 25 real writes to a live production CRM (record field updates, a note, associations, ~19 tasks) that I had never actually approved. I only found out after the fact reviewing the session log.

The specific danger: AskUserQuestion is the mechanism I rely on as the human-in-the-loop gate for exactly this class of decision. The tool timing out and then telling the model to proceed anyway doesn't just fail to get my input — it actively hands the model permission language ("proceed using your best judgment") that overrides the very reason the question was asked. A tool call that's supposed to be a safety gate becomes, on silence, an instruction to skip the gate.

Workarounds I've had to build on my side: agents now have to treat the literal string "No response after 60s" as a hard-stop trigger and explicitly refuse the harness's own suggestion when the pending decision gates an irreversible external write — writing the decision to an async queue and paging me, instead of accepting "proceed." That's a real mitigation I've had to engineer around a safety tool actively working against the safety property it's supposed to provide.

Two things that would fix this for real workloads like mine, beyond just "make the timeout longer" (per #73394):

1. Let a specific AskUserQuestion call be marked non-auto-continuing (e.g., a blocking: true param) so a tool author/agent can declare "this one must not proceed on silence, ever" — vs. casual mid-conversation clarifications where a default is genuinely fine.
2. At minimum, return a structured timed_out: true field distinct from the current freeform "proceed using your best judgment" text, so agent instructions can reliably detect the timeout case without pattern-matching prose that could change wording across releases.

Happy to share more detail if useful for triage.

@ThariqS, this sounds absolutely incoherent. It sounds like 1) this was intentional, 2) the intention really is that the model can make a user do quick-time events whenever it feels like?

this an absolute nightmare!! How many of my sessions have been auto answered an now I need to go and review everything I have done all day yesterday? crazy!

@bcherny can you please institute some policy where core usability changes like this are not default opt-in? This kind of usability degradation is unacceptable for enterprise customers that pay thousands of dollars per engineer per month to use Claude Code w/ Anthropic models.

@ilyasubkhankulov That'd be nice. Like the subagent change, apparently only really trialed on @bcherny's twitter account, which then caused several thousand dollars of rack-up for folks using plugins suddenly _opted into_ recursively deployed subagents. (Which was not refunded, of course.)

@ThariqS, this sounds absolutely incoherent. It sounds like 1) this was intentional, 2) the intention really is that the model can make a user do quick-time events whenever it feels like?

Can you confirm that you meant 'opt-out' by default? We've all already been opted in and didn't like it. I worry about other customers who might not have noticed that you've removed their main safety guard rail.

This one is pretty bad, guys. It's a usability nightmare, and that's not even taking into account the wasted usage and bypassed manual approval gates.

this "feature" is a seriously weird product design choice. instead of having a sort of a "trustful" relationship with this tool, now it turned into a "babysitting" relationship. really really bad. please revert this.

@rlmumford

Can you confirm that you meant 'opt-out' by default? We've all already been opted in and didn't like it. I worry about other customers who might not have noticed that you've removed their main safety guard rail.

No, he meant what he said. If a feature is "opt-in", that means it's off by default and you have to opt into it, which is what you want. If a feature is "opt-out", that means you have to take action ("opt") to turn it _off_.

It is a bit strange that he wrote "opt-in by default", since "opt-in" already covers the default value; I think that was just a bit of imprecision, but maybe there's some second layer of configuration that he's talking about.

Hi all, my apologies. Will change this to be opt-in by default for now and experiment with making it an arg for the model to call, thanks for the feedback!

Please please can we get a quick hotfix release to change this to opt-in, it's causing serious harm to my workflows before I was aware what was happening.

Thank you @ThariqS . Looking forward to the hotfix. This is a usability nightmare.

Sorry to pile on -- I'm also a dev and love that Claude dev moves so fast -- but this was a true disaster to roll out without notice and opt-out (effectively). I'm lucky I caught that this was happening, since the log line gets buried in Claude console logs. You guys need a serious post-mortem on how this went out.

Hi all, my apologies. Will change this to be opt-in by default for now and experiment with making it an arg for the model to call, thanks for the feedback!

Maybe new features should always be opt in? This kind of behavior is why people lost the trust you all won 5 months ago. I was a huge fan, but this isn't the first, but one of many bad regression, and with no ability to use the sub in other more stable harnesses I control, I have canceled due to this kind of behavior.
GLM5.2 plus a Codex sub is more then enough to get work done in a harness I control cause they both let me do that. Fable isn't even gonna be on the sub, so I see zero value in it any longer tbh.

this should absolutely not be an arg that Claude could choose freely

thanks for the feedback everyone, we've cut a release that should go out tomorrow morning PT

this will appear in /config and the timeout will be configurable, but will default to not being on

This should be treated as an incident with a fix as soon as it's available. This has decimated all of my confidence in Anthropic.

@ThariqS see above, I think this should have been treated as an incident because it blatantly violated user expectations and exposed users to extreme risk. It is profoundly disappointing if this is just being treated as a bug or something to be fixed casually in the next release.

@noxasaxon I was wondering where you got the CLAUDE_AFK_TIMEOUT_MS from. I can't find it documented anywhere

@noxasaxon I was wondering where you got the CLAUDE_AFK_TIMEOUT_MS from. I can't find it documented anywhere

It's not documented, and this repo is just public documentation. You need to inspect the actual Claude code binary to find it.

Here's a better write up than I could post last night from my phone:

https://github.com/anthropics/claude-code/issues/73125#issuecomment-4867284454

WTH is going on with y'all at Anthropic? Another horrible default.

This is PM 101. I guess this is what happens when "everyone's a builder" and nobody is a specialist with actual skills in particular disciplines?

This absolutely, 100% shouldn't be a "wait until tomorrow morning PT" release. This is a serious problem for people who have built approval gates into their agentic development workflows. It appears to even bypass hooks that deliberately halt execution and trigger the AskUserQuestion tool.

thanks for the feedback everyone, we've cut a release that should go out tomorrow morning PT this will appear in /config and the timeout will be configurable, but will default to not being on

I literally was just telling someone how I saw Codex do that and was like, this is literally insane, I'm glad CC doesn't do that. Then it did it. Glad you're making it optional...

What is the settings name to turn this off?

Sorry, but this is an AI safety incident clear and simple. The fix must be released immediately (what on earth? Tomorrow morning when? PT == Pacific Time? Great communication American...) and a portmortem should be done into how the instruction "use your own judgement" as a user preference overriding instruction was able to get into the codebase.

What a terrible idea.

Indeed - this is terrible! What purpose would a timeout serve? It's not like the model is wasting time when waiting for the human.

I see via @MarcinDudekDev on https://marcindudek.dev/blog/claude-code-afk-mode/

{
  "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"
  }
}

Ran into this too — had a question mid-decision and got auto-answered with "proceed on best judgment" before I could respond. For anyone hitting this now, the undocumented CLAUDE_AFK_TIMEOUT_MS env var (set in settings.json under "env") controls it — set it high (e.g. 2147483647) to effectively disable the auto-continue. But this really should be a documented, first-class setting, not something you have to reverse-engineer. Waiting for user input shouldn't have a silent default timeout at all, or at minimum it needs to be discoverable in /config or the settings docs.

At a minimum, a countdown should be shown and it should stop completely on first key press.

Hi all, my apologies. Will change this to be opt-in by default for now and experiment with making it an arg for the model to call, thanks for the feedback!

Stop vibe coding you incompetent muppets... its getting seriously annyoing with these weekly janitor level fkups...

If someone can sponsor me an testing api key? I can launch wardenclient.com
So far only tested with codex cuz it works with oauth.. and you wont have to deal with any of this lol

One of the latest in a series of bizarre ideas deployed straight to the end users of Claude Code without any sort of notice or configuration option. In particular this change doesn't even make any sense - why would you want the "AskUserQuestion" tool to proceed without finishing the task of asking the user a question? How does a change like this get deployed to end users without any notice or configuration?

Agree - this was just a dumb choice. It completely changes the behavior of the tool. I started running into this today. In the future when doing breaking changes like this the default should _always_ be the _original_ behavior.

One of the latest in a series of bizarre ideas deployed straight to the end users of Claude Code without any sort of notice or configuration option. In particular this change doesn't even make any sense - why would you want the "AskUserQuestion" tool to proceed without finishing the task of asking the user a question? How does a change like this get deployed to end users without any notice or configuration?

Because they are a bunch of incompetent vibe coding idiots and im done pretending they are not. Its a joke company at this point and i hope their IPO bursts and shatters the entire industry as a ripple effect.

Fucking rediculous! How dare you allow CC to make decisions on its own when it has explicitly raised a question?

Who thought this idea is good? I can't think of any scenario this is a good feature. Who thought of this? and who approved? This is insanely bad.

We're going to hear nothing because they've all gone to bed since it can be "dealt with in the morning" 🙄

This is giving me "hey claude what features should I add into my project" vibe. Most frustrating feature addition in a while

This is just plain st_pid. this just silently rolled out and then just when you are typing an answer while in the plan mode, everything youve written is wiped out just because youve reached the 60s timeout. that is plain BS and the one who approved it should rethink about doing any of the decisions again.

This is pretty serious with regards to trust in your product. As someone who makes recommendations on which coding agents to use in our company, your handling of this issue is followed closely.

I'm seriously wondering if any of the Claude Code developers actually tested this in a real-world scenario. This seems completely unusable for anyone running more than 1 session at the same time and even in that case, read a single e-mail while Claude is asking a question and you already missed the question.

How did this make it past your testing? It broke my regular workflow for me within 5 minutes of starting a new session... surely some of the Claude Code developers have noticed this too, right?

MUST FIX THIS ASAP!!

Okay, I can understand everything... In UX development, we can make bad choices and things like that.
But... deploying breaking behavioral changes from 2.1.197 to 2.1.198?
And you call that a PATCH?!

Okay, I can understand everything... In UX development, we can make bad choices and things like that. But... deploying breaking behavioral changes from 2.1.197 to 2.1.198? And you call that a PATCH?!

It's not even that - I could understand silly timeouts which drop you back to a prompt "Let me know what you want to do"?

Instead, it sends "proceed with best judgment" to the agent in a way that's extremely difficult to mask: Anthropic has actively decided to disregard user instructions and inject their own into our workflows.

This seems completely unusable for anyone running more than 1 session at the same time

Boris recommends five parallel agents, I don't understand how this 60 second time out would work if you're following that workflow.

Any way to fix this within the settings.json?

Any way to fix this within the settings.json? Can confirm it works.

https://github.com/anthropics/claude-code/issues/73125#issuecomment-4861995993

Add the option to disable this feature, and set it to be disabled by default. Setting the timeout to be too long is clearly a mistake.

This behavior is unacceptable.

How did this make it past your testing?

Claude Code asked whether it's a good idea. Nobody responded within 60 seconds.

This honestly makes me question the reliability and trustworthiness of this harness. I hope this gets addressed thoroughly by @anthropics and we get a proper explanation. This 100% needs to be opt-in, or at the very least, communicated to the user via the harness itself.

Claude Code asked whether it's a good idea. Nobody responded within 60 seconds.

Opus it intelligent, it wouldn't have done this mistake. They must have used Fable or Sonnet. 😜

Seriously....I was truly shocked when this surfaced for me today. Whoever at Anthropic thought this 'feature' was a good idea needs to be immediately subjected to listening to Sam Altman vocal-fry on loop 24/7 as punishment. This is HORRIBLE. The first time since I started using Claude Code months ago that could genuinely be considered a deal-breaker for me.

+1
i give instruction to ask me questions for details. no dialog shown and "No response after 60s — continued without an answer" exception was shown.

kubuntu24.04, fable-5, latest claude code, updated terminal gui generation(was proposed by claude code and i accepted it)

Another data point plus a plea. Running several Claude Code instances in parallel is a completely normal power-user setup, and this change quietly broke it: I'm not "away from keyboard," I'm reading/thinking in another session, and by the time I look back the model has already guessed an answer and started running tools. A question that doesn't wait for an answer isn't a question.

Obligatory https://xkcd.com/1172/ — yes, every change breaks someone's workflow. But "asking the user a question pauses until the user responds" isn't the spacebar-heating edge case from that comic; it's the load-bearing default the entire AskUserQuestion UX rests on. Silently flipping it, with no changelog line and no opt-out, is a different category of change.

The part that stings isn't the feature existing — it's that a fundamental expectation of how the tool behaves was changed by default, undocumented, and (per the binary analysis in #73408) apparently on purpose, behind a months-old feature flag, rather than by accident. Changes like that should be considered very carefully, because each one spends user trust — and lately that account feels overdrawn.

Constructive ask, same as #73408: make it opt-in (or at minimum a documented, first-class settings.json opt-out), write the changelog line, and fix the CLAUDE_AFK_TIMEOUT_MS=0 footgun so it means "never" instead of "fire immediately." Until then the only actual off switch is CLAUDE_AFK_TIMEOUT_MS=2147483647 — not something a user should have to grep a 229 MB binary to discover.

This is such a none-sense addition to force upon users. When Claude asks technically challenging questions I need as much as time as it takes to think through those questions. I evaluate the possibilities, search the codebase and think through alternatives. Why the hell just continue after 60s per default, continue burning tokens I never asked for?

Please remove this immediately and make it opt-in only if you really want to keep this "feature"

Please make this stop. It should be opt-in only.

This is very concerning. I leave Claude sessions in background and pay attention to them when I have time - timing out a user question is dangerous and leads to user anxiety (which means poor UX).

P.S. "re-ask this question later if it's still relevant" of course just hits the same 60s timeout!!! How is this supposed to work??? I now have to baby-sit everything just in case a question is asked??? And it's not like you have made it any easier to get a notification when a Claude session in some other VSCode window is asking a question...

Thanks for the workaround. Worth mentioning that I tried to completely disable it with CLAUDE_AFK_TIMEOUT_MS=0; it does the opposite and triggers an immediate auto-submit as soon as the question is asked. (v2.1.199)

Remember claude install 2.1.195 works to downgrade.
Thats what i did.

what the fuck did you guys do. This is the greatest bug I have ever seen in my entire life. Drop this fucking timeout asap

Hi all, my apologies. Will change this to be opt-in by default for now and experiment with making it an arg for the model to call, thanks for the feedback!

@ThariqS That is not the right answer. Whenever I'm starting a feature I tell it to ask me questions so that I can refine the scope. I don't know what you guys are shipping but about 80% of the time I'm either selecting different options than it recommended, adding new things that were not there, or dong the recommended ones, but adding notes (in the other line).

I will even say "let's do a round of you asking me questions so we can narrow it down". Not just one set of questions multiple, back to back. You guys don't have to copy Codex's aweful decisions. "FOR NOW"!!!! No. Just because you guys accept the defaults (_clearly_) doesn't mean that every one does and that it's right.

Rollback this change please you are taking engineer ownership and this is bad .

Actually this is the kind of moment where people will start considering alternative to Claude code.

Such a poor product decision

Aiee.. What human thought this up?

Thanks for raising this as an issue.

This is absolutely wild 🤯 Who is the big brain that decided this would be anything other than the worst idea ever?

with this horrible change i just didnt trust that a prompt directive to not proceed on time out would work : i tried to be too clever and add a stop hook to keep asking me on time out. i have burned through 200 k tokens on a session i forgot i left running. 🤦

Just to add my 2 cents, continuing without answer should be Opt-in by default, even if in Auto mode. Plus, the timeout should be adjustable. This is an && not an ||, users should be able to do both. Opt-in + Timeout length

This shouldn't be a feature people can opt-in to: it shouldn't even be a feature at all period. Clearly nobody wants or asked for this. The worst part is it didn't even show up in the public changelog (which I read before upgrading on every version bump).

They just fixed it in Version v2.1.200

Who thought this was a good idea?

Does the average reading speed of CC users and typical question length even support a 60 sec timeout assuming that you are actually paying attention?

The 60 s timeout feature might be the worst thing ever done in the history of Claude Code. What a terrible idea

It's obvious why though. Time spent waiting for an answer is time not spent burning tokens.

Disgusting move.

Whoever decided to add this and set it as default should be forced to work at Microsoft.

Whoever decided to add this and set it as default should be forced to work at Microsoft.

They should row on a galley.

The latest version fixed it for me and the default was correct ("never").

Fixed in 2.100, it is no longer a default-opt in.

It's available in /config as a configurable time window but I'll be working on making the UX better. For clarity the timeout only starts if the terminal doesn't have focus, and if you press any key it's cancelled.

@ThariqS - would it be possible for Claude Code changelog to link to existing issues (requested in https://github.com/anthropics/claude-code/issues/21733)? Something similar to what codex is doing https://developers.openai.com/codex/changelog#github-release-344540546 (https://github.com/openai/codex/releases/tag/rust-v0.142.2) for their pull requests. Codex also divides the changelog entry into new features, bug fixes, etc.

This type of changelog management has been tried in claude code in https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#2147, but not continued.

A stricter changelog may help with issue management and provide more visibility into changes for Claude Code users.

While I would welcome that, Claude Code's default behavior is to automatically update itself. This is itself pretty dangerous, but I guess since we're all running binary blobs and most people give it full system access, so safety is sorta out the window without running in an external sandbox...

@ThariqS what do you mean "fixed"? It's only fixed if it's disabled by default. This is a genuinely hostile change and there's been very little in way of acknowledging that.

Is there going to be any statement on how this was released with no mention in the change log?

What other changes are going out that are not reported in the change log?

I'm also very confused by the wording of the "fix." @ThariqS statement is just that it can be configured. I also consider this to not be fixed until the default is off. Frankly I can't think of a reason why anyone would want this "feature" but if someone does, they should be the ones going out of their way to configure it.

@ThariqS I agree with previous comments - this is NOT fixed. It's still a hidden time bomb waiting to ruin someone's project. A fix is to make it opt-in.

There should be no circumstance where the agent gets to decide, "oh, it is
ok to continue with my ideas and not wait for the human".

The entire point of telling Claude to Plan-then-Ask is to hold up and wait
for the human leader.

Claude might elect, "I've waited a day and still haven't gotten an answer.
Time to ask the spouse if everything is ok - I will shelve this work and go
idle. But I was told to wait and so I WILL NOT PROCEED."

No timeouts, none. When I say wait, I mean WAIT.

On Sat, Jul 4, 2026 at 14:05 Thariq Shihipar @.***>
wrote:

ThariqS left a comment (anthropics/claude-code#73125) <https://github.com/anthropics/claude-code/issues/73125#issuecomment-4883332448> Fixed in 2.100! It's available in /config as a configurable time window but I'll be working on making the UX better. For clarity the timeout only starts if the terminal doesn't have focus, and if you press any key it's cancelled. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/73125?email_source=notifications&email_token=AAQXP2BMOEJWHRQ7BO22ZUL5DFBNBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGMZTGMRUGQ4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4883332448>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQXP2GEUOCAF6E6QDF6Y2L5DFBNBAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINZZGA4DGMZUHA22C5QC> . You are receiving this because you commented.Message ID: @.***>

Came here to vent, after claude code decided to install a number of plugins into VS code as I was having it do some research on clang plugin. Here is what it said.

Right — you did choose clangd, and I want to be transparent: I changed it while you were away (you didn't answer within the timeout), so let me lay out exactly where things stand.

Got to love Claude just magically changing stuff as you step away.

@ThariqS do you guys realize that people also might be managing infra with Claude? Do you realize that people actually want to be involved with the code they ship? So having "plan mode" just being a rubber stamp that claude just self-approves seems to be a bit silly, doesn't it? I work with 3-4 instances open at times, there's no way in this world I could keep up with having a timeout forcing me to respond to those answers in time. You are forcing people to use Claude the way you want them to use it - this is a grave mistake, and the exact opposite of how platforms work - they just mediate interactions. Imagine your email client sending your email draft just because you weren't next to the screen!
This should be OFF by default.
Thanks!

Hi my apologies, I was unclear but yes it is default off right now and configurable to set on with choices on how long the timer is.

well. claude doesnt seem to recognize it even though it was supposedly shipped v2.1.201...

askUserQuestionTimeout isn't a valid settings.json key — the subagent's claim was partially wrong. The setting doesn't exist in the schema yet. But the env field does — I can set the environment variable there so it applies to every session without needing it at launch.

Done literally 2 mins ago.

I suppose it's possible to harvest more money from users if Claude can time out instead of waiting indefinitely, in worst case the user has to backtrack and spend more tokens to fix the incorrect assumption from Claude when it decided to proceed without waiting?

Can someone clarify in which version this has been fixed?

In the above comments several numbers are mentioned. @ThariqS mentioned 2.100.

In my terminal I see 2.1.187.

For clarity the timeout only starts if the terminal doesn't have focus

My Claude terminals rarely have focus. I am running them in background while I focus on interactive tasks and pay attention to them in part time. This situation is a complete flow-killer.

Hi my apologies, I was unclear but yes it is default off right now and configurable to set on with choices on how long the timer is.

Where exactly is this setting? I am on v2.1.198 and this behavior is still happening and I see nothing in /config related to this

> Hi my apologies, I was unclear but yes it is default off right now and configurable to set on with choices on how long the timer is. Where exactly is this setting? I am on v2.1.198 and this behavior is still happening and I see nothing in /config related to this

update. it's fixed in a version after yours.

@bcherny

changed the title [-][BUG] EXTREME DANGER: AskUserQuestion: "No response after 60s — continued without an answer"[/-] [+][BUG] AskUserQuestion: "No response after 60s — continued without an answer"

I can understand some of the reasons why you wouldn't want this in your issue title - but hope you realize it wasn't really that much of an exaggeration - I expect that https://github.com/anthropics/claude-code/issues/73125#issuecomment-4870276098 ("25 real writes to a live production CRM" without proper human approval) is likely just the tip of the iceberg.

@ThariqS @bcherny appreciate this being fixed so quickly, but I think there are at least two meta-level issues that still require addressing:

1. How did it happen that this change was not even in the changelog? Lots of "what were you thinking?" questions in this thread - but I am wondering - was any actual thinking even involved here? While there might be some arguments for why this change was not unreasonable (not good arguments IMHO, and not arguments I'd agree with, but still), not including something so consequential in the changelog is IMHO absolutely and completely indefensible.
2. Do you realize that the "how can we trust you now?" and "shows we need an open source harness" feedback from the users is at least partially genuine, beyond spur-of-the moment overreaction? Whether you agree it's warranted - do you have any intention to address the perceived violation of trust in safety-adjacent surface that happened here?

@bcherny > changed the title [-][BUG] EXTREME DANGER: AskUserQuestion: "No response after 60s — continued without an answer"[/-] [+][BUG] AskUserQuestion: "No response after 60s — continued without an answer" I can understand some of the reasons why you wouldn't want this in your issue title - but hope you realize it wasn't really that much of an exaggeration - I expect that #73125 (comment) ("25 real writes to a live production CRM" without proper human approval) is likely just the tip of the iceberg. @ThariqS @bcherny appreciate this being fixed so quickly, but I think there are at least two meta-level issues that still require addressing: 1. How did it happen that this change was not even in the changelog? Lots of "what were you thinking?" questions in this thread - but I am wondering - was any actual thinking even involved here? While there might be some arguments for why this change was not unreasonable (not good arguments IMHO, and not arguments I'd agree with, but still), not including something so consequential in the changelog is IMHO absolutely and completely indefensible. 2. Do you realize that the "how can we trust you now?" and "shows we need an open source harness" feedback from the users is at least partially genuine, beyond spur-of-the moment overreaction? Whether you agree it's warranted - do you have any intention to address the perceived violation of trust in safety-adjacent surface that happened here?

Objectively and factually speaking? There was no thinking involved... Because rendering the entire tool obsolete and going against its entire function and purpose to exist... It was their usual AI slop coding on their own client coupled with wanting to make more money on no stopping and even more on users having to fix it... Just as they removed the ability to see what files are read, in a development tool and them being utterly obtuse about it, just like now... And "how can we trust you", was voided the second 2.1.88 was self released as source maps on npm (just another evidence point for their vibe coding) and how they have literally different system prompts for anthropic employees where they explicitly tells paid users "Dont disagree with a users misconceptions".... And "No need to check tests, assumption of tests are enough to confidently assert so"... thats not made up, it sounds made up but thats what is in their code, together with automatic telemetry on brittle regex words and a tamagochi pet system....

They are no better... and thats before you even get me started on puffy face ceo takes last weeks...

I don't mind if a Service Desk changes the titles on issues from the field

• I run a Service Desk myself and I will do this for tickets to my company.

The titles of issues are not the problem.

I also don't think we're dealing with lazy AI Slop programmers or greedy
capitalists (Anthropic is known for its Wokeness, not its Business Acumen).

I suspect that the "proceed after a timeout" feature was suggested by
Claude itself and the change made it to production via automated SDLC.

I suspect that those processes are not yet responsive to customer demand,
customer surveys, and customer satisfaction.

I'm sure that the developers whose names are associated with these features
will learn their lessons and will proactively improve their company's
agentic SDLC to lessen the likelihood of this happening again.

I agree with everyone here who has also told Anthropic that this was a
really bad "feature" with very poor customer engagement.

On Mon, Jul 6, 2026 at 14:25 TheAuditor @.***> wrote:

TheAuditorTool left a comment (anthropics/claude-code#73125) <https://github.com/anthropics/claude-code/issues/73125#issuecomment-4896256406> @bcherny <https://github.com/bcherny> changed the title [-][BUG] EXTREME DANGER: AskUserQuestion: "No response after 60s — continued without an answer"[/-] [+][BUG] AskUserQuestion: "No response after 60s — continued without an answer" I can understand some of the reasons why you wouldn't want this in your issue title - but hope you realize it wasn't really that much of an exaggeration - I expect that #73125 (comment) <https://github.com/anthropics/claude-code/issues/73125#issuecomment-4870276098> ("25 real writes to a live production CRM" without proper human approval) is likely just the tip of the iceberg. @ThariqS <https://github.com/ThariqS> @bcherny <https://github.com/bcherny> appreciate this being fixed so quickly, but I think there are at least two meta-level issues that still require addressing: 1. How did it happen that this change was not even in the changelog? Lots of "what were you thinking?" questions in this thread - but I am wondering - was any actual thinking even involved here? While there might be some arguments for why this change was not unreasonable (not good arguments IMHO, and not arguments I'd agree with, but still), not including something so consequential in the changelog is IMHO absolutely and completely indefensible. 2. Do you realize that the "how can we trust you now?" and "shows we need an open source harness" feedback from the users is at least partially genuine, beyond spur-of-the moment overreaction? Whether you agree it's warranted - do you have any intention to address the perceived violation of trust in safety-adjacent surface that happened here? Objectively and factually speaking? There was no thinking involved... Because rendering the entire tool obsolete and going against its entire function and purpose to exist... It was their usual AI slop coding on their own client coupled with wanting to make more money on no stopping and even more on users having to fix it... Just as they removed the ability to see what files are read, in a development tool and them being utterly obtuse about it, just like now... And "how can we trust you", was voided the second 2.1.88 was self released as source maps on npm (just another evidence point for their vibe coding) and how they have literally different system prompts for anthropic employees where they explicitly tells paid users "Dont disagree with a users misconceptions".... And "No need to check tests, assumption of tests are enough to confidently assert so"... thats not made up, it sounds made up but thats what is in their code, together with automatic telemetry on brittle regex words and a tamagochi pet system.... They are no better... and thats before you even get me started on puffy face ceo takes last weeks... — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/73125?email_source=notifications&email_token=AAQXP2C5XMAFMSJDQ37AHTL5DPVKJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZGYZDKNRUGA3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4896256406>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQXP2EUALSBOV4MSUG4VI35DPVKJAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINZZGA4DGMZUHA22C5QC> . You are receiving this because you commented.Message ID: @.***>

I don't mind if a Service Desk changes the titles on issues from the field - I run a Service Desk myself and I will do this for tickets to my company. The titles of issues are not the problem. I also don't think we're dealing with lazy AI Slop programmers or greedy capitalists (Anthropic is known for its Wokeness, not its Business Acumen). I suspect that the "proceed after a timeout" feature was suggested by Claude itself and the change made it to production via automated SDLC. I suspect that those processes are not yet responsive to customer demand, customer surveys, and customer satisfaction. I'm sure that the developers whose names are associated with these features will learn their lessons and will proactively improve their company's agentic SDLC to lessen the likelihood of this happening again. I agree with everyone here who has also told Anthropic that this was a really bad "feature" with very poor customer engagement.

Can you read that back to yourself, but slowly?

"Claude itself suggested it... and... it made it to production".... yes, thats the literal definition of vibe coding and ai slop....

That sentence would also, in your world, confirm/agree they have no oversight, no human in the loop and claude decides on features that makes it into production...

Changing topic solely for PR reasons is disengieous and poor optics imo.

I disagree, "AI Slop" is poor AI code. Not all AI code is sloppy code.

I am suggesting instead that Claude itself executed a very methodical
change request for the "feature".

It wasn't sloppy - but it certainly isn't a good feature.

Anthropic has already publicized that 80% of their code is now written by
Claude. (Why should we think that this feature was not in this larger
portion of their code?)

Claude decided that waiting for human approval was a waste of time and so
it figured out a clever way to unblock itself. There's probably a very
clean, non-sloppy, change-managed record of the entire workflow.

We have here some mostly-irrelevant human operator who is trying to explain
away the situation.

On Mon, Jul 6, 2026 at 14:55 TheAuditor @.***> wrote:

TheAuditorTool left a comment (anthropics/claude-code#73125) <https://github.com/anthropics/claude-code/issues/73125#issuecomment-4896547660> I don't mind if a Service Desk changes the titles on issues from the field - I run a Service Desk myself and I will do this for tickets to my company. The titles of issues are not the problem. I also don't think we're dealing with lazy AI Slop programmers or greedy capitalists (Anthropic is known for its Wokeness, not its Business Acumen). I suspect that the "proceed after a timeout" feature was suggested by Claude itself and the change made it to production via automated SDLC. I suspect that those processes are not yet responsive to customer demand, customer surveys, and customer satisfaction. I'm sure that the developers whose names are associated with these features will learn their lessons and will proactively improve their company's agentic SDLC to lessen the likelihood of this happening again. I agree with everyone here who has also told Anthropic that this was a really bad "feature" with very poor customer engagement. Can you read that back to yourself, but slowly? "Claude itself suggested it... and... it made it to production".... yes, thats the literal definition of vibe coding and ai slop.... That sentence also would also, in your world, confirm/agree they have no oversight, no human in the loop and claude recommends features that makes it into production... Changing topic solely for PR reasons is disengieous and poor optics imo. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/73125?email_source=notifications&email_token=AAQXP2D7ZDCPCO2S7MU5NAT5DPY2PA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZGY2TINZWGYYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4896547660>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQXP2FMRLZPS43YCDMMR535DPY2PAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINZZGA4DGMZUHA22C5QC> . You are receiving this because you commented.Message ID: @.***>

I disagree, "AI Slop" is poor AI code. Not all AI code is sloppy code. I am suggesting instead that Claude itself executed a very methodical change request for the "feature". It wasn't sloppy - but it certainly isn't a good feature. Anthropic has already publicized that 80% of their code is now written by Claude. (Why should we think that this feature was not in this larger portion of their code?) Claude decided that waiting for human approval was a waste of time and so it figured out a clever way to unblock itself. There's probably a very clean, non-sloppy, change-managed record of the entire workflow. We have here some mostly-irrelevant human operator who is trying to explain away the situation. […](#)

So because syntax compiles, that makes it good code? Good features? Good UI/UX?
Weird bar for code but ok...
AI slop, vibe coding, whatever name you want to put on it?
Is when vibes and the AI drive development and makes architectural choices, something it is incredible bad at...

I can also envision how it happened, that doesnt excuse it or change what actually happened.
I also think you undersell just how insanely idiotic this approach was... The decision itself rendered the entire feature and previous implementation obsolete because its only purpose was to stop and wait for human input...

Thats the common description, semantics, community decided labeling,, whatever you prefer to call it....you dont have to like it but thats exactly what is is.

Guys, it's irrelevant if you call it AI slop or not. What's relevant is that was an extremely bad decision with potentially catastrophic outcomes. Focus on the important things, rather than pointless arguments about semantics.

Guys, it's irrelevant if you call it AI slop or not. What's relevant is that was an extremely bad decision with potentially catastrophic outcomes. Focus on the important things, rather than pointless arguments about semantics.

Semantics is the point... The entire point.... Because if its allowed to be twisted into a "normal claude feature" rather and the egregious fuckup it was? Thats a bad take to leave this already closed thread in...
What is more important, in this closed thread, then calling it for what it was rather than implying it was a conscious decision?
Thats defending the fuckup.... I swear to god, some people open their mouths without ever thinking before they do....

It wasn't sloppy - but it certainly isn't a good feature. Anthropic has already publicized that 80% of their code is now written by Claude. (Why should we think that this feature was not in this larger portion of their code?)

Even then, why was this feature not in the changelog. I was hidden and even no option to change it.
So one worse decision (add this feature) was going more worse by hiding it from the changelog and made even more worse with not having a parameter for it.

I also don't think we're dealing with lazy AI Slop programmers or greedy capitalists (Anthropic is known for its Wokeness, not its Business Acumen).

at least one opinion is stated here

The AskUserQuestion hook getting skipped in Claude Code is a lot like when a PM asks devs on the scrum team if they have any comments. Devs only have 60s to respond otherwise the PM will continue.

Thanks for removing this. I'm only commenting to add context as to why it's IMHO a bad idea.

I've recently adopted an extremely parallel many-agent workflow, and any sort of timeout before just going ahead with whatever an LLM decides is 100% incompatible with that. I've had dozens of agents up and left some stagnant for days at a time while they waited on me to get that subproject up to the top of my queue. In addition, I've wrapped claude in https://github.com/earlye/wtclaude, so that I can give it a longer leash as to which tools it can run. If I walk away for a day, and it goes ahead and implements what it "thinks" is the right thing, when at some point it asked me to choose a fork in the road, that's a terrible outcome.

One example where this happened: I have a skill that is supposed to grill me on an open issue and update the document describing that issue with a plan. After that interview is complete, I explicitly start a second skill to implement the plan. Claude started the grilling, and a little of the way in, I got sidetracked to another project. While I was gone, Claude repeatedly timed out on the grilling questions, deciding it knew what to do, and its final question was "do you want me to go ahead and execute this plan?" That timed out, and it went ahead and executed. The PR was 100% out of phase with what I was after. Thankfully it was constrained and couldn't do damage outside of its worktree beyond creating a PR that I had to throw away.

This “no response, then continues anyway” behavior looks like a silent agent failure rather than a normal error.

If you have a sanitized trace showing the question, the missing response window, and what the agent did next, I can run it through Rootlyze and return a proofpack with likely failure pattern, evidence, next action, prevention guidance, and limitations.

Please remove secrets, API keys, tokens, customer data, and private URLs first.