Approval covers a different dimension: may this specific operation proceed. It is an independent knob from sandbox mode; the docs bundle the two into named permission presets for the UI.
| Policy | Meaning | Risk |
|---|---|---|
| ask | Every operation needing approval asks you | Safe, but noisy for high-frequency work |
| never | No asking; allow | Smooth, but you gave up this layer of review |
The key design: fail closed
Outcomes are a closed set: allowed-once, rejected, cancelled, unavailable. The docs are explicit: only allowed-once permits; the other three are treated as refusal. A missing, non-responsible, or throwing answerer yields unavailable, not permission.
allowed-once really is once
The name is deliberate: this grant does not extend to the next similar operation. So 'I approved once and it ran a pile of commands' should not happen by design — if it does, the cause is elsewhere.
The two default presets
| Preset | Bundle | Good for |
|---|---|---|
| workspace-write | workspace-write sandbox + ask approval | The default. Enough for daily work; crossing the line asks you |
| danger-full-access | danger-full-access sandbox + never approval | When you know you need out of confinement. Both layers open |
Note that danger-full-access opens both: sandbox bypassed and approval silenced. It is not 'just one of them'. Think about both consequences before choosing it.
Choosing
- Daily work that edits files →
workspace-write. - Read-only analysis where an accidental write is unacceptable → read-only + ask.
- danger-full-access only for two cases: you are in a disposable environment, or you know exactly what this run does. Do not use it to save a few clicks.