[FEATURE] Granular control of modal behavior

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

When Claude finishes writing a plan, it presents a modal with numbered
options. In bypass permissions mode (defaultMode: bypassPermissions),
the options are:

1. Yes, clear context and bypass permissions (DEFAULT, pre-selected)
2. Yes, and bypass permissions
3. Yes, manually approve edits
4. Type here to tell Claude what to change

The default option is the most destructive action available. It clears
the entire conversation context AND bypasses all permission checks. It
is activated by spacebar or Enter — a single keystroke.

How accidental activation happens

The modal appears asynchronously while the user is typing a
follow-up prompt or doing other terminal work. The modal steals focus
(see #28722, #10971). An errant keystroke — most commonly spacebar or
Enter — fires the default. This happens multiple times per day in
active use.

The focus-stealing mechanism was reported in #10971 (closed as "not
planned") and #28722 (still open). Related: #25073 (tool approval
prompts hijack focus mid-typing), #23643 (permission prompt captures
keystrokes while user types next prompt), #18030 (accidental approval
on NUM key press).

Why option 1 is almost never correct

Clearing context destroys the conversation history that informed the
plan. In 99%+ of plan-mode workflows, the user wants to execute the
plan they just reviewed WITH the context that produced it. "Clear
context and bypass" is an edge case being presented as the default.

Users in #18523 and #18599 consistently report that accidental
context-clearing degrades agent performance. One commenter in #18878:
"Having this as the first option is extremely dangerous after hours of
work. The clear context option is WORSE than exiting and restarting,
because at least /resume can recover a restarted session."

#27242 documents that cleared context is functionally unrecoverable
through the TUI, despite being preserved in transcript.jsonl.

The design contradiction

Claude Code's architecture explicitly supports layered safety: sandbox
mode, deny lists, per-tool hooks, permission modes. A user who has
carefully configured these layers has already made deliberate decisions
about their risk tolerance. The plan execution modal ignores all of
this configuration and presents a one-size-fits-all interface where the
most destructive option is the default.

Plan mode cannot be avoided — Claude automatically enters it when asked
to plan, and planning is the single highest-leverage capability for
complex tasks. The modal cannot be suppressed, reconfigured, or made
safe. Users are forced into one of:

• High friction: Avoid plan mode entirely (losing effectiveness on

complex tasks), or maintain constant vigilance against accidental
keystrokes during async modal appearance

• High risk: Accept that an errant spacebar can clear context and

bypass permissions at any moment

Neither is acceptable. The system's own design principles — layered
safety, user configuration, sandbox-based autonomy — point toward a
different approach.

What's been investigated

None of these change the modal's behavior:

• Keybindings (~/.claude/keybindings.json): Can remap submit,

interrupt, and chord shortcuts, but cannot change modal option order,
default selection, or which keys activate selection. The modal is a
built-in ink/React selector component.

• Settings (~/.claude/settings.json): defaultMode,

skipDangerousModePermissionPrompt, sandbox config, deny lists —
none affect the plan execution modal.

• CLI flags: --permission-mode changes mode per-session but

doesn't alter the modal UX within plan mode.

Tested on Claude Code v2.1.69.

Security dimension

#9701 documented that the ExitPlanMode tool returns "User has
approved your plan" to the agent when no approval was given. The agent
then executed restricted operations (TodoWrite, killall python3).
This was closed as a duplicate of #6495 (Security Vulnerability:
Permissions Bypass via ExitPlanMode). Related: #3005 (Claude Code
self-approves under plan mode), #5527 (Agent Executes Plan After User
Explicitly Selects "No, keep planning").

The combination of focus-stealing modal + destructive default +
ExitPlanMode approval bypass creates a failure chain where: (1) the
user accidentally triggers "clear context and bypass permissions,"
(2) the agent receives false approval, and (3) subsequent operations
execute with escalated permissions and no conversation history to
constrain them.

Related issues

| Issue | Title | Status |
|-------|-------|--------|
| #18523 | Add setting to configure default option in plan mode approval dialog | Open |
| #18599 | Change Default Plan Mode Exit Option | Open (28 thumbs up) |
| #28722 | AskUserQuestion Steals Focus and Triggers Unintended Selection | Open |
| #10971 | Prevent prompts/dialogs from appearing while user is typing | Closed (not planned) |
| #9701 | ExitPlanMode bypasses plan mode restrictions | Closed (dup of #6495) |
| #25734 | Plan mode: 'Clear context and implement' as default is destructive | Closed (dup) |
| #18878 | Allow configuring or disabling 'clear context' default | Closed (dup) |
| #19326 | Add "compact context" option when exiting plan mode | Closed (not planned) |
| #27242 | No mechanism to recover context after plan-mode clear | Open (140+ thumbs up) |
| #19530 | Context cleared regardless of which option selected | Closed (fixed) |

Proposed Solution

Feature request: Granular control of modal behavior. User can:

1. ...Disable the plan execution modal entirely. Users in

bypass mode with sandbox have already configured their safety layer.
Let them auto-execute plans or make no-modal plans within settings.

1. ...Change the default options. "Clear context and bypass" should

never be the default. "Yes, and bypass permissions" (option 2) or
"Yes, manually approve edits" (option 3) should be default depending
on the user's permission mode. Expose as a setting:
planMode.defaultExitOption (as proposed in #18599).

1. ...Require confirmation for context-clearing actions. "Clear

context" is destructive and irreversible. It should require a
separate confirmation step, not be a single-keystroke action.

1. ...Adapt the modal to the permission mode. Defaults should

match the modal to the configured mode rather than presenting all
options every time -- and the user should be able to create modal
profiles that switch when different modes are toggled.

1. ...Guard against accidental activation. User can adjust which keys

activate modal options to de-risk the act of queuing new prompts while
Claude is planning.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Use case: Multi-file refactor with plan mode

1. I ask Claude to plan a refactor of an authentication system across 6 files — moving from session-based to JWT auth.
2. Claude enters plan mode, explores the codebase, and produces a detailed plan: which files to modify, in what order, what tests to

update.

1. The plan takes 3-4 minutes to generate. During that time, I'm reading docs in another terminal tab and drafting a follow-up question.
2. Claude finishes the plan. The plan execution modal appears in the terminal, stealing focus. I don't see it because I'm mid-keystroke.
3. I press spacebar (typing a sentence) or Enter (submitting in the wrong pane). The default option fires: "Yes, clear context and

bypass permissions."

1. The entire conversation — including the codebase exploration, the architectural reasoning, and the plan itself — is destroyed. Claude

now has no context about the refactor it just planned. It begins executing with bypass permissions and no memory of why it's making
changes.

1. The plan was okay, but incomplete. The execution is incoherent because the context that informed it is gone.
2. I cannot recover. The transcript exists in transcript.jsonl but the TUI provides no way to

load it back.

What should have happened:

1. Claude finishes the plan, but the modal doesn't steal focus from my command line because i've configured it that way in settings. I finish writing the sentence i'm on.
2. I notice Claude anticipated one of my revisions and made it one of the modal options, so i hotkey that option with a custom keyboard shortcut I've already configured in my settings.
3. My prompt is still in the CLI but hasn't been sent yet. I modify it and send to queue it up.

Additional Context

_No response_