[FEATURE] Configurable default selection in permission prompts (default to 'No' in sandbox mode); add 'deny for this session' option
Resolved 💬 3 comments Opened Mar 18, 2026 by BryceEakin Closed Mar 21, 2026
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Permission prompts currently default to \"Yes\" — the first option is pre-selected, so pressing Enter approves the action. This is a footgun when:
- You're actively typing a message to redirect an agent and accidentally hit Enter while a prompt is on screen
- A sandboxed agent decides to make 70+ network requests to the same URL and you don't want a stray keystroke to approve it
In sandbox mode specifically, defaulting to \"Yes\" actively works against the user's intent — the whole point of sandbox mode is cautious, restricted execution.
Proposed Solution
- Configurable default selection: Add a setting (e.g.
permissions.defaultPromptSelection: "yes" | "no") so users can choose whether permission prompts default to \"Yes\" or \"No\". The current \"Yes\" default would remain the out-of-the-box behavior for non-sandbox sessions.
- Sandbox mode default: When running in sandbox mode, the default selected option in permission prompts should be \"No\", not \"Yes\". Sandbox implies caution — the default should reflect that, but at a minimum it should be configurable.
- \"No, and don't ask again for this resource\" option: Add a session-scoped deny option to suppress repeat prompts for the same URL/resource within the current session. When an agent hammers the same endpoint repeatedly, having to consciously deny each request is tedious and increases the chance of an accidental approval.
Why This Matters
The current behavior optimizes for convenience at the expense of safety. For users running agents in sandbox mode or managing agents that make repetitive requests, the risk of accidental approval is real and the blast radius can be significant (e.g. unintended network egress, rate limit consumption, unintended writes).
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗