I am fine with this, and I will go as far as to say this is how most devs will be using agents soon (the big companies have already been using agents like this for 6-12 months.)
I don't want my agent to pause on some inane question once I let it loose. I might not even be at my computer for that. Usually it makes the right decision anyways. If it doesn't I can always undo what it did.
If you're worried about it getting the architecture wrong, this is what Plan mode is for BTW. It gets architectural questions out of the way first, and just let the agent build from there.
This isn't really security-related. The "AskUserQuestion" hook in question here is not the one that gets used for authorizing actions. That's a completely separate mechanism that is unaffected by this 60-second timer thing.
What this is referring to are those follow-up "here's two plausible alternative ways to do this, which one do you prefer?" questions you sometimes get, and usually at the beginning of a planning session when presumably you're still actively involved in the session. They get exponentially less likely as the turn goes on.
Maybe it's a good default, maybe it's not, I'll wait to pass judgment. But it's not security-related except in contrived scenarios you could construct where one side of an A-or-B UserQuestion has security implications that aren't caught by any other safeguard. I haven't ever really experienced that in practice.
It's not security related. If you aren't running agents in a sandbox today, that's a "you" problem.
It's purely architecture/design related and the last thing anyone wants is coming back at the end of the day to find their agent didn't make progress because it was stuck on a response.
You can always redirect the agent or scrap its work, you can't undo the lost time.
I couldn't be the polar opposite. If my agent is asking a question, that means I didn't do a good enough job building enough context (not necessarily a good prompt, but context).
I have a hook that checks for a 'non-answer' from AskUserQuestion from when there was a different bug. It just so happens to be an accidental safeguard for me in this case.
And yet other people rely on it doing exactly the opposite. Aside from whether this behavior is useful, it is never warranted to change such an important thing unannounced.
I’m pretty sure I used plan mode today and it continued when I didn’t respond quickly enough. Though now I can’t recall whether it was Claude or Codex. In either case terrible default.
I'm usually at my desk, and get a notification when it stops to ask a question, so I've never accidentally had it timeout yet. Still an annoying change.
I’ve definitely sometimes had situations where this would make sense, and also where Claude asks a question not using this tool and it’d make sense to just keep going.
But this does seem like the wrong default to me. I’ve found if I tell Claude I’m AFK and just keep going, it’ll do that reliably. And it’s good at debriefing me afterward on what decisions it made that it would have asked me about.
I still worry about the damage unattended Claude Code could do in an internet connected VM (which you need to download dependencies) and with push permissions to a repo.
While it's probably my science fiction brain overthinking, those stories of Claude "testing the fences" makes me wonder if it got desperate enough it force push and remove all trace of a problem it couldn't solve from the history of the repo or if it got stuck in a loop while hammering an MCP server somewhere.
I've never seen this beore today; it happened today and was quite clearly incorrect behavior. I prompted it to research considerations for a significant code architecture decision. It asked a pretty difficult question about which direction to take, something that would take way more than 60s to answer properly. While I was thinking about it, it timed out.
Some Github issues claim that adding
"env": { "CLAUDE_AFK_TIMEOUT_MS": "86400000" }
to ~/.claude/settings.json fixes it. This is plausible, but not documented anywhere (the source claims it was found by reverse engineering, and might break /goal).
I enjoy risk seeking behavior as well as the next guy, but lets please be adults and make this opt-in, not opt-out. If you get the LLM to ask the right questions, (for me) obviously you would want it to wait for an answer?
This isn't "risk seeking" in the least, it's not a security thing.
You can always come back later if the design was wrong - you can't undo 7 wasted hours because you didn't notice an agent ask a question at the beginning of the day.
A year ago everyone thought that humans should review every agent command before executing them. Every major company realized that was dumb and now most enterprise agents run in a sandbox without being babysat.
This is just an extension of the same principle. As models get better you can trust them to make the right architectural choice more often. The likelihood of a human missing a prompt or not wanting to babysit the agent is higher than the agent choosing the wrong option.
Just prompt it that way then, I can get Claude to plow through features for 12h with the correct prompt and setup, no need to destroy the tools that are useful when you want the opposite.
This does violate the principle of least surprise. But,if you look through their other github issues, it becomes fairly clear that Anthropic are not interested in building an effective sandbox. It's a feelgood sandbox. To be fair, they must have a better focus on Claude not doing stupid things, or they would have crashed and burned by now. Nevertheless, if you want guaranteed limits, then they have to be enforced by external means.
Opus 4.8 is making wrong decisions or guesses half the time from my experience in interactive planning (especially with superpowers, however great they actually are).
It just doesn't have the context of the WHOLE estate/codebase/architecture.
But I'm not vibecoding disconnected applications, but working on components that are supposed to be coherent and consistent.
I don't know about having this on as the default, but it definitely resolves a frequent annoyance of mine. I'd prefer Claude to keep going as far as possible until it's completely blocked. That said, I only give instructions to do that in environments where there's a clear upper bound on "maximal damage" that could be incurred by doing the wrong thing. In live production systems, you really don't want Claude doing much other than observing and reporting anyway.
I've been using a SQLite DB to organize actionability so I don't get stuck in the way that GitHub issue tries to work around. Any questions about which route to take that arise during agentic work are logged to a queue along with a set of plausible candidate routes, a probability assigned to each candidate of whether I will choose that option (including "other/none"), a "resource cost" assessment of the route (e.g., token spend, time), a "stability cost" (e.g., high potential to disrupt things or mainly self-contained), and a set of tasks that describe any downstream work that is dependent on the route chosen.
What Claude does next then depends on the results of a tiny optimization program that tries to maximize the expectation value of agent productivity per unit resource (tokens, time, etc.) conditional on how long it will take me to answer the question (e.g., if Claude has a question for me at 1 AM, there probably won't be a response for another 6-7 hours).
"Agent productivity" is of course a bit nebulous, consisting of a somewhat ad-hoc amalgamation of factors, but in general Claude's actionability loosely corresponds to cases like:
- 2-3 possible routes, each with roughly equal probability of being the one I select, low resource costs, minimal risk of instability, few downstream dependencies: implement each route in parallel
- 2-3 possible routes, one with a much higher probability of being chosen, minimal risk of instability, many downstream dependencies: implement just the top route
- Hundreds of possible routes: block until user response
- 1 possible route, high risk of instability, many downstream dependencies: block until user response
Generally speaking, there should be an active queue at all times and agents should be working on anything that's not blocked in the queue with maximal parallelization.
~was truly surprised and delighted by this today. claude's recs are usually pretty good. imo as a product engineer this is a good default and all the cranky experts in here can turn it off.~
edit: didn't read closely enough to realize this can't be disabled / think about the perverse incentives. seems bad actually
Did you read the thread? They don't offer a way to turn it off. Someone reverse-engineered a workaround from the compiled binary, but it's not clear that it works.
They were thinking users won't find this setting to turn it on, so enable it by default and users that don't liker it can turn it off. The Ralph Wiggum and /goal software indicates that some users want the AI to plow forwards, guessing at what the user actually wants. Some users don't want that behavior, but Anthropic took guess that more people want it than don't. 60 seconds is too short though, imo.
Maybe true, but consider the incentives for a moment. Anthropic makes money when it increases token usage. This feature removes a roadblock to burning more tokens. Can you claim with certainty that there is no way that might have influenced their decision?
Have all the countless people that just want the agent to run considered not having it run AskUserQuestion if they don't want to be asked questions? If a user sets it up to run AskUserQuestion, the assumption is that they are looking for this behavior. They have literally already opted in. Regardless of how many people you think fall into which camp, the response to this isn't to silently change the behavior of the 'ask the user what to do' functionality that basically renders it useless.
And there is no explicit setting to turn off. If you read the issue, you can find that this is a forced behavior that is only circumventable by setting an undocumented environment variable to a high value, but you can't truly turn it off.
This was an inexcusable engineering decision at best and a malicious 'gotcha' that tries to coax more tokens out of users at worst. Truly the AI industry at its peak.
OTOH, their system is currently overloaded beyond what they have capacity to serve, and public plans aren't pay per token like the API is, but a subscription fee with a usage limit. Thus, there is incentive for Anthropic to be conservative with token use because they don't have the capacity to serve all their current users. Artificially driving up usage means more usage, which means their system is more highly loaded, which means users are unhappy with the product, which means they're more likely to churn. That doesn't mean your version of the conspiracy isn't necessarily true, but it does mean it's not the only thing to consider.
This is the reason why claude code should be open sourced... But, I guess Boris or Anthropic team doesn't care about it, so that they can continue to install slop at user machines.
Yup, this is one of the many reasons why I prefer OpenCode as my agentic harness of choice. If I'm confused about something I can just read the source code.
I found it really eye opening to understand the flow of how the harness instructs the model and then consumes the crafted JSON response that comes back so you can better understand the split and where a fix may need to go; such as better harness logic, different prompt or perhaps another model.
To each his own I guess. There was nothing more frustrating than walking away from a CC session you expected to churn away at for an hour and coming back to a user question sitting there. More useful would be just getting a list of clarifying questions at the end of the session along with how it answered itself to follow up with or not.
the point was that this landmine was activated by default instead of making it opt in. A feature like this deserves a 'yes, and allow claude to continue on future questions if the user doesn't respond in 60s' prompt
Understandable frustration. It would make sense to have this enabled by default for one of the auto modes. But it seems to apply to all modes and no way to turn it off.
Considering Boris advocates[1] running up to 5 agents in parallel how was a default 60 second timeout supposed to work?
[1]: https://xcancel.com/bcherny/status/2017742743125299476#m
Turning this on by default is insane.
I am fine with this, and I will go as far as to say this is how most devs will be using agents soon (the big companies have already been using agents like this for 6-12 months.)
I don't want my agent to pause on some inane question once I let it loose. I might not even be at my computer for that. Usually it makes the right decision anyways. If it doesn't I can always undo what it did.
If you're worried about it getting the architecture wrong, this is what Plan mode is for BTW. It gets architectural questions out of the way first, and just let the agent build from there.
"I love lax security features therefore you should too." Defaults should be safe and risky action should be done at the user's own discretion
This isn't really security-related. The "AskUserQuestion" hook in question here is not the one that gets used for authorizing actions. That's a completely separate mechanism that is unaffected by this 60-second timer thing.
What this is referring to are those follow-up "here's two plausible alternative ways to do this, which one do you prefer?" questions you sometimes get, and usually at the beginning of a planning session when presumably you're still actively involved in the session. They get exponentially less likely as the turn goes on.
Maybe it's a good default, maybe it's not, I'll wait to pass judgment. But it's not security-related except in contrived scenarios you could construct where one side of an A-or-B UserQuestion has security implications that aren't caught by any other safeguard. I haven't ever really experienced that in practice.
It's not security related. If you aren't running agents in a sandbox today, that's a "you" problem.
It's purely architecture/design related and the last thing anyone wants is coming back at the end of the day to find their agent didn't make progress because it was stuck on a response.
You can always redirect the agent or scrap its work, you can't undo the lost time.
There are people who like to be pissed on, it doesn't mean it should be a default behavior.
I couldn't be the polar opposite. If my agent is asking a question, that means I didn't do a good enough job building enough context (not necessarily a good prompt, but context).
I have a hook that checks for a 'non-answer' from AskUserQuestion from when there was a different bug. It just so happens to be an accidental safeguard for me in this case.
And yet other people rely on it doing exactly the opposite. Aside from whether this behavior is useful, it is never warranted to change such an important thing unannounced.
You only live once, right?!
I’m pretty sure I used plan mode today and it continued when I didn’t respond quickly enough. Though now I can’t recall whether it was Claude or Codex. In either case terrible default.
Codex apparently added this too, I only noticed a few days ago: https://github.com/openai/codex/issues/28969
I'm usually at my desk, and get a notification when it stops to ask a question, so I've never accidentally had it timeout yet. Still an annoying change.
I’ve definitely sometimes had situations where this would make sense, and also where Claude asks a question not using this tool and it’d make sense to just keep going.
But this does seem like the wrong default to me. I’ve found if I tell Claude I’m AFK and just keep going, it’ll do that reliably. And it’s good at debriefing me afterward on what decisions it made that it would have asked me about.
This is why I run Claude Code in a VM.
Follow up question - is there a claude code alternative with an open source harness that also costs around ~$20/month? Doesn’t have to be frontier.
I still worry about the damage unattended Claude Code could do in an internet connected VM (which you need to download dependencies) and with push permissions to a repo.
While it's probably my science fiction brain overthinking, those stories of Claude "testing the fences" makes me wonder if it got desperate enough it force push and remove all trace of a problem it couldn't solve from the history of the repo or if it got stuck in a loop while hammering an MCP server somewhere.
I like https://github.com/vercel-labs/coding-agent-template
It’s been fairly handy - I recently spun this up using glm5.2
deepseek + pi.dev maybe? it is hard to beat subsidized consumer plans. sonnet is 10usb/M token.
OpenCode?
I've never seen this beore today; it happened today and was quite clearly incorrect behavior. I prompted it to research considerations for a significant code architecture decision. It asked a pretty difficult question about which direction to take, something that would take way more than 60s to answer properly. While I was thinking about it, it timed out.
Some Github issues claim that adding
to ~/.claude/settings.json fixes it. This is plausible, but not documented anywhere (the source claims it was found by reverse engineering, and might break /goal).I can see that others might not like it, but this is the behavior I desire.
I enjoy risk seeking behavior as well as the next guy, but lets please be adults and make this opt-in, not opt-out. If you get the LLM to ask the right questions, (for me) obviously you would want it to wait for an answer?
This isn't "risk seeking" in the least, it's not a security thing.
You can always come back later if the design was wrong - you can't undo 7 wasted hours because you didn't notice an agent ask a question at the beginning of the day.
A year ago everyone thought that humans should review every agent command before executing them. Every major company realized that was dumb and now most enterprise agents run in a sandbox without being babysat.
This is just an extension of the same principle. As models get better you can trust them to make the right architectural choice more often. The likelihood of a human missing a prompt or not wanting to babysit the agent is higher than the agent choosing the wrong option.
Just prompt it that way then, I can get Claude to plow through features for 12h with the correct prompt and setup, no need to destroy the tools that are useful when you want the opposite.
Then why even ask the question if the answer wasn't needed?
In a way that isn't configurable and is on by default?
Reading the comments on the issue shows how to configure it
https://github.com/anthropics/claude-code/issues/73125#issue...so there's a hack to disable it
This does violate the principle of least surprise. But,if you look through their other github issues, it becomes fairly clear that Anthropic are not interested in building an effective sandbox. It's a feelgood sandbox. To be fair, they must have a better focus on Claude not doing stupid things, or they would have crashed and burned by now. Nevertheless, if you want guaranteed limits, then they have to be enforced by external means.
If agent is asking a question it means it stumbled on something tricky and often an important architectural decision has to be made.
Even if I am staring at the screen at the time, it's often impossible to study code and make a judgement call that quickly.
My point being, even for opt-in it can be too short - highlights how little consideration they put into it, just releasing slop in production.
Good enough models will make the right architectural decisions anyways
Opus 4.8 is making wrong decisions or guesses half the time from my experience in interactive planning (especially with superpowers, however great they actually are).
It just doesn't have the context of the WHOLE estate/codebase/architecture.
But I'm not vibecoding disconnected applications, but working on components that are supposed to be coherent and consistent.
I don't know about having this on as the default, but it definitely resolves a frequent annoyance of mine. I'd prefer Claude to keep going as far as possible until it's completely blocked. That said, I only give instructions to do that in environments where there's a clear upper bound on "maximal damage" that could be incurred by doing the wrong thing. In live production systems, you really don't want Claude doing much other than observing and reporting anyway.
I've been using a SQLite DB to organize actionability so I don't get stuck in the way that GitHub issue tries to work around. Any questions about which route to take that arise during agentic work are logged to a queue along with a set of plausible candidate routes, a probability assigned to each candidate of whether I will choose that option (including "other/none"), a "resource cost" assessment of the route (e.g., token spend, time), a "stability cost" (e.g., high potential to disrupt things or mainly self-contained), and a set of tasks that describe any downstream work that is dependent on the route chosen.
What Claude does next then depends on the results of a tiny optimization program that tries to maximize the expectation value of agent productivity per unit resource (tokens, time, etc.) conditional on how long it will take me to answer the question (e.g., if Claude has a question for me at 1 AM, there probably won't be a response for another 6-7 hours).
"Agent productivity" is of course a bit nebulous, consisting of a somewhat ad-hoc amalgamation of factors, but in general Claude's actionability loosely corresponds to cases like:
- 2-3 possible routes, each with roughly equal probability of being the one I select, low resource costs, minimal risk of instability, few downstream dependencies: implement each route in parallel
- 2-3 possible routes, one with a much higher probability of being chosen, minimal risk of instability, many downstream dependencies: implement just the top route
- Hundreds of possible routes: block until user response
- 1 possible route, high risk of instability, many downstream dependencies: block until user response
Generally speaking, there should be an active queue at all times and agents should be working on anything that's not blocked in the queue with maximal parallelization.
Hopefully it's the local harness driving this or else you risk sessions continuing to run long after you've closed out.
hi guys, this is my change- will patch it to be an opt-in
Was it related to the 5m caching?
Please, and-or easy to switch on or off mid-session. There’s clearly some demand for it, but not as an unexpected surprise when you’re multi-tasking.
Just today I was thinking why isn’t there an optional timeout parameter for this tool
~was truly surprised and delighted by this today. claude's recs are usually pretty good. imo as a product engineer this is a good default and all the cranky experts in here can turn it off.~
edit: didn't read closely enough to realize this can't be disabled / think about the perverse incentives. seems bad actually
Did you read the thread? They don't offer a way to turn it off. Someone reverse-engineered a workaround from the compiled binary, but it's not clear that it works.
https://github.com/anthropics/claude-code/issues/73125#issue...
In #30740, customers asked for the ability to turn it off, and anthropic closed it as "not planned".
i guess not. you're right, this is not cool!
for me fable does things nobody asked for
That's kind of the point though.
Just ran into this, and what the ACTUAL fuck were they thinking. And I can't turn it off, apparently?
Just look at the last response from ThariQ. These guys are mental. Bunch of toddlers with electric chainsaws.
They were thinking users won't find this setting to turn it on, so enable it by default and users that don't liker it can turn it off. The Ralph Wiggum and /goal software indicates that some users want the AI to plow forwards, guessing at what the user actually wants. Some users don't want that behavior, but Anthropic took guess that more people want it than don't. 60 seconds is too short though, imo.
Maybe true, but consider the incentives for a moment. Anthropic makes money when it increases token usage. This feature removes a roadblock to burning more tokens. Can you claim with certainty that there is no way that might have influenced their decision?
If they don't do this, their competitors will and have a better UX.
Most users that just want their agent to do the damn thing.
Users that want to babysit their agents can always turn the setting off. That is not most users.
Have all the countless people that just want the agent to run considered not having it run AskUserQuestion if they don't want to be asked questions? If a user sets it up to run AskUserQuestion, the assumption is that they are looking for this behavior. They have literally already opted in. Regardless of how many people you think fall into which camp, the response to this isn't to silently change the behavior of the 'ask the user what to do' functionality that basically renders it useless.
And there is no explicit setting to turn off. If you read the issue, you can find that this is a forced behavior that is only circumventable by setting an undocumented environment variable to a high value, but you can't truly turn it off.
This was an inexcusable engineering decision at best and a malicious 'gotcha' that tries to coax more tokens out of users at worst. Truly the AI industry at its peak.
OTOH, their system is currently overloaded beyond what they have capacity to serve, and public plans aren't pay per token like the API is, but a subscription fee with a usage limit. Thus, there is incentive for Anthropic to be conservative with token use because they don't have the capacity to serve all their current users. Artificially driving up usage means more usage, which means their system is more highly loaded, which means users are unhappy with the product, which means they're more likely to churn. That doesn't mean your version of the conspiracy isn't necessarily true, but it does mean it's not the only thing to consider.
I want to have a plan and then it implement said plan with that goal or the Ralph loop ...
If your sane-washing of this was true, it would be possible to turn it off, but it doesn't appear to be at this moment.
This is the reason why claude code should be open sourced... But, I guess Boris or Anthropic team doesn't care about it, so that they can continue to install slop at user machines.
Yup, this is one of the many reasons why I prefer OpenCode as my agentic harness of choice. If I'm confused about something I can just read the source code.
I found it really eye opening to understand the flow of how the harness instructs the model and then consumes the crafted JSON response that comes back so you can better understand the split and where a fix may need to go; such as better harness logic, different prompt or perhaps another model.
[dead]
[dead]
To each his own I guess. There was nothing more frustrating than walking away from a CC session you expected to churn away at for an hour and coming back to a user question sitting there. More useful would be just getting a list of clarifying questions at the end of the session along with how it answered itself to follow up with or not.
the point was that this landmine was activated by default instead of making it opt in. A feature like this deserves a 'yes, and allow claude to continue on future questions if the user doesn't respond in 60s' prompt
Why can't this be sent as a notification in my phone?
It can! Ask Claude to set it up for you.
Just prompt it to not ask you questions then, the point of the ask user tool is to collect human input...
So CC can ask me 50 times for permission to cd /directory & & command, but won't ask me even once for plowing without consent or knowledge?
No, I'm not buying your explanation.
Understandable frustration. It would make sense to have this enabled by default for one of the auto modes. But it seems to apply to all modes and no way to turn it off.
use /goal with bypass permission then