Repository navigation
YOLO #435
Description
Problem (one or two sentences)
It's so annoying to have to press confirmation and permission buttons for every tiny little step. It's impossible to get any work done. I hate the allowed/blocked commands list. There can be thousands of commands, but you can only add them to the allowed list one at a time through the UI.
Context (who is affected and when)
When working
Desired behavior (conceptual, not technical)
We need a YOLO mode to approve the plan ONCE, hit execute, and then go do our own thing — not sit around waiting for yet another mouse click on some button.
Constraints / preferences (optional)
No response
Request checklist
- I've searched existing Issues and Discussions for duplicates
- This describes a specific problem with clear context and impact
Zoo Code Task Links (optional)
No response
Acceptance criteria (optional)
No response
Proposed approach (optional)
No response
Trade-offs / risks (optional)
No response
Activity
mkf commentedon Sep 20, 2026
First time around here, and I'm surprised there doesn't seem to be an issue for enhancing the allowlist behavior. I attributed that to there surely being a YOLO mode that everyone must have switched to. The allowlist is pretty error-prone on the user part — allowing
find,timeout,do, is something asked from a user and I suppose those are actually as dangerous as to allow any args.The command-line restrictions are an age-old problem that has been dismissed for decades since
rbash. Utilities were not designed as capability dealers in mind — except in rare, setuid cases. It is a bad combination of the equivalent of "restricted classloader" inadequacies with the prevalence of Unix composability ideas. Writing a comfortable allowlist solution comes down to either making a compromise and making an LLM the judge, or… I think individually evaluating all kinds of builtins&coreutils with special heuristics, if not getting a full specialized shell implementation that likely replaces a lot of stuff with builtin wrappers.mkf commentedon Sep 20, 2026
I see there is work towards a way more permissive system #1049
DaubnerF commentedon Oct 2, 2026
There is a pr in the pipeline that solves what you want, but with a little bit more security than what yolo would offer: issue #1569 / pr #1760
Idea: destructive command guard is already available, and it auto-allows a lot of commands, while the more dangerous ones get routed to the user for approval. In practice, this solves only half of the issue, as the models invent more and more complicated commands that dcg can't evaluate, so the requests get routed to the user anyway. The part that this new pr solves is that it auto-denies what is not auto-allowed, giving the model the reason why it was denied so it can adapt.
For the user, this is quite similar to yolo mode, as nothing needs approval anymore.