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.
- 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.
- For chained commands (several commands combined into one), the denial names the specific offending part and states clearly that the entire chain was 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.
- A denial applies only to the offending command; the rest of the work in that turn continues and is judged on its own merits, rather than a whole turn being skipped as if the user had clicked reject.
- The feature only engages when command auto-approval is switched on; with the master auto-approval switch off, users still get prompts as today.
- If the guard itself is broken or times out, that stays a retryable error rather than pretending to be a policy denial.
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.
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:
Constraints/Preferences
Related issues