Problem
When approving an exit_plan_mode request from the HAPI web UI, the current PermissionFooter only sends a bare approval without any additional options. This creates two limitations:
1. No post-plan permission mode selection
The web approval calls approvePermission(sessionId, permissionId) without a mode parameter (PermissionFooter.tsx:143). The CLI handler defaults to 'default' mode (permissionHandler.ts:242), so there's no way to start implementation with acceptEdits or bypassPermissions from the web UI.
The "Allow all edits" button is hidden for exit_plan_mode (PermissionFooter.tsx:134-135), and there's no equivalent selector.
2. No keep_context / clear_context option
The current implementation always uses queue.unshift() which preserves the existing context (permissionHandler.ts:240-243). There's no way for the user to choose clear_context (clear the Claude session and restart fresh with just the approved plan).
This matters because:
- Long planning sessions accumulate context that may confuse the implementation phase
clear_context would need to clear claudeSessionId, reset permission allowlists, and drain the message queue to prevent stale prompts from leaking into the fresh session
3. Stale queue entries leak into clear_context restarts
Even if clear_context were implemented, using queue.unshift() / queue.unshiftIsolate() preserves the rest of the queue. Any user messages queued before approval would replay into the fresh session, leaking old-context instructions.
Relevant code
cli/src/claude/utils/permissionHandler.ts:233-248 — exit_plan_mode approval handler
cli/src/claude/utils/permissionHandler.ts:296-300 — bypassPermissions (YOLO) path
web/src/components/ToolCard/PermissionFooter.tsx:134-144 — web approval UI (no mode selector)
Expected behavior
The exit-plan-mode approval flow should allow the user to:
- Choose a post-plan permission mode (
default / acceptEdits / bypassPermissions)
- Choose an implementation mode (
keep_context / clear_context)
- If
clear_context, properly drain the queue and reset session state
cc @xyzhang626 (working on this in #413 — this issue tracks the underlying bugs independently of that PR's scope)
Problem
When approving an
exit_plan_moderequest from the HAPI web UI, the currentPermissionFooteronly sends a bare approval without any additional options. This creates two limitations:1. No post-plan permission mode selection
The web approval calls
approvePermission(sessionId, permissionId)without amodeparameter (PermissionFooter.tsx:143). The CLI handler defaults to'default'mode (permissionHandler.ts:242), so there's no way to start implementation withacceptEditsorbypassPermissionsfrom the web UI.The "Allow all edits" button is hidden for
exit_plan_mode(PermissionFooter.tsx:134-135), and there's no equivalent selector.2. No
keep_context/clear_contextoptionThe current implementation always uses
queue.unshift()which preserves the existing context (permissionHandler.ts:240-243). There's no way for the user to chooseclear_context(clear the Claude session and restart fresh with just the approved plan).This matters because:
clear_contextwould need to clearclaudeSessionId, reset permission allowlists, and drain the message queue to prevent stale prompts from leaking into the fresh session3. Stale queue entries leak into
clear_contextrestartsEven if
clear_contextwere implemented, usingqueue.unshift()/queue.unshiftIsolate()preserves the rest of the queue. Any user messages queued before approval would replay into the fresh session, leaking old-context instructions.Relevant code
cli/src/claude/utils/permissionHandler.ts:233-248— exit_plan_mode approval handlercli/src/claude/utils/permissionHandler.ts:296-300— bypassPermissions (YOLO) pathweb/src/components/ToolCard/PermissionFooter.tsx:134-144— web approval UI (no mode selector)Expected behavior
The exit-plan-mode approval flow should allow the user to:
default/acceptEdits/bypassPermissions)keep_context/clear_context)clear_context, properly drain the queue and reset session statecc @xyzhang626 (working on this in #413 — this issue tracks the underlying bugs independently of that PR's scope)