Problem / Value
Today, a command that is neither auto-approved nor explicitly denied always interrupts the user with a confirmation prompt. In autonomous hands-free sessions - especially with the Destructive Command Guard enabled - the model regularly invents novel commands or complex command chains that nothing auto-approves, so the session stalls waiting for a click that may never come. An opt-in blanket auto-deny that rejects everything not explicitly approved, and tells the model exactly why, would make hands-free operation actually work: fewer interruptions, no stalling, and a model that can adapt instead of getting confused.
Context
Affects users who run Zoo Code autonomously (long unattended tasks, batch/automation use). Today they face two unsatisfying options: accept prompts that block progress, or loosen approvals and risk executing things they never vetted.
Desired behavior, in plain terms:
- A new opt-in setting, "Auto-deny unapproved commands (never ask)", off by default, living in the auto-approval settings for command execution and available both with and without the Destructive Command Guard. The control is shown in the command-execution area of the auto-approval settings whether or not the guard is enabled. The setting is stored like the other auto-approval settings, so it keeps its value across restarts.
- When enabled, command execution never prompts: anything explicitly approved runs as usual, and everything else is automatically denied - with the denial reason sent back to the model instead of silence; a command the shell cannot parse still ends as a retryable error rather than a denial.
- The denial reaches the model as a JSON tool result rather than freeform prose: a denial status, a type marker that distinguishes an automatic policy denial from a user rejection, the reason, the offending command when one can be named, and - when the Destructive Command Guard produced the denial - its rule reference. A structured result is used because the model has to act on the denial.
- A chained command means a single command string that combines several commands with shell operators (
&&, ||, ;, pipes, &, or unquoted newlines). Every part of the chain is evaluated, and the denial names the part that triggered it - the first denied part when the denylist matches, otherwise the first part that nothing explicitly approves. The entire chain is rejected and nothing in it ran - so the model is not confused about what already happened and can rerun the remaining approved parts separately.
- When the Destructive Command Guard is on: commands it approves run; commands it blocks are auto-denied and the reason from the guard (and its rule reference) is passed on to the model. A guard block is final - an allowlist entry cannot override it.
- An automatic denial is a policy outcome, not a user rejection. It applies only to the offending command: the rest of the work in that turn continues and is judged on its own merits, and none of the side effects of a user clicking reject (whole-turn skip, user-feedback message) are triggered.
- The feature engages only while command auto-approval is fully engaged: both the master auto-approval switch and the command-execution auto-approval toggle must be on. Its checkbox lives in the command-execution section, so that toggle controls its visibility; with the master switch off the checkbox stays visible but has no effect. In every other case command prompts proceed as today.
- If the guard itself is broken or times out, that stays a retryable error rather than pretending to be a policy denial: failing to install or run the guard, or output that cannot be parsed, ends the command attempt as a retryable tool error. Only a completed guard run can produce a deny verdict.
Constraints/Preferences
- Off by default; behavior is completely unchanged for everyone who does not enable it.
- The reason given to the model must never suggest asking the user for approval - in hands-free mode that would trigger follow-up questions and defeat the purpose.
- Scoped to command execution only; file edits, reads, and other approval categories keep today's behavior.
- Existing confirmation dialogs and rejection behavior for real user clicks stay exactly as they are.
Out of scope
Injecting the list of auto-approved commands into the system prompt so the model knows up front what it may run was proposed in the comments here. It is a complementary change of a different kind - prompt content rather than approval policy - and belongs in its own issue. This feature does not alter the prompt.
Related issues
Problem / Value
Today, a command that is neither auto-approved nor explicitly denied always interrupts the user with a confirmation prompt. In autonomous hands-free sessions - especially with the Destructive Command Guard enabled - the model regularly invents novel commands or complex command chains that nothing auto-approves, so the session stalls waiting for a click that may never come. An opt-in blanket auto-deny that rejects everything not explicitly approved, and tells the model exactly why, would make hands-free operation actually work: fewer interruptions, no stalling, and a model that can adapt instead of getting confused.
Context
Affects users who run Zoo Code autonomously (long unattended tasks, batch/automation use). Today they face two unsatisfying options: accept prompts that block progress, or loosen approvals and risk executing things they never vetted.
Desired behavior, in plain terms:
&&,||,;, pipes,&, or unquoted newlines). Every part of the chain is evaluated, and the denial names the part that triggered it - the first denied part when the denylist matches, otherwise the first part that nothing explicitly approves. The entire chain is rejected and nothing in it ran - so the model is not confused about what already happened and can rerun the remaining approved parts separately.Constraints/Preferences
Out of scope
Injecting the list of auto-approved commands into the system prompt so the model knows up front what it may run was proposed in the comments here. It is a complementary change of a different kind - prompt content rather than approval policy - and belongs in its own issue. This feature does not alter the prompt.
Related issues