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).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.
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.
edit: didn't read closely enough to realize this can't be disabled / think about the perverse incentives. seems bad actually