[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

  1. 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.
  1. 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.
  1. \"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).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗