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.