Turning this on by default is insane.

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

I can see that others might not like it, but this is the behavior I desire.

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.

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

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

for me fable does things nobody asked for

Just ran into this, and what the ACTUAL fuck were they thinking. And I can't turn it off, apparently?

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.

[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.