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.
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.
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.
It’s been fairly handy - I recently spun this up using glm5.2
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.
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.
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.
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.
"env": {
"CLAUDE_AFK_TIMEOUT_MS" : "<massive number>"
}
edit: didn't read closely enough to realize this can't be disabled / think about the perverse incentives. seems bad actually
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".
No, I'm not buying your explanation.
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 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.
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.
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.