Skip to content

Instantly share code, notes, and snippets.

@fcoury
Created April 11, 2026 21:43
Show Gist options
  • Select an option

  • Save fcoury/de88e7249f2165e7e7beff560ad93849 to your computer and use it in GitHub Desktop.

Select an option

Save fcoury/de88e7249f2165e7e7beff560ad93849 to your computer and use it in GitHub Desktop.

What The Option Does When enabled, the dialog prepends one clear-context approval option before the normal “keep context” options:

  • Auto available: Yes, clear context (...) and use auto mode
  • Bypass available: Yes, clear context (...) and bypass permissions
  • Otherwise: Yes, clear context (...) and auto-accept edits

That option is built in src/components/permissions/ExitPlanModePermissionRequest/ExitPlanModePermissionRequest.tsx:691.

When the user chooses it, the permission dialog does not allow the current ExitPlanMode tool call. Instead it:

  1. Picks the post-clear permission mode:
    • yes-bypass-permissions -> bypassPermissions
    • yes-accept-edits -> acceptEdits
    • yes-auto-clear-context -> auto only if the auto gate is still enabled, otherwise default behavior applies
  2. Creates a new pending initialMessage:
    • content starts with Implement the following plan:\n\n${currentPlan}
    • appends the old transcript path so the model can recover details from before the clear
    • appends team-parallelization guidance if swarms are enabled
    • appends any approval feedback the user typed
    • stores planContent: currentPlan for UI/recovery metadata
  3. Sets clearContext: true, the chosen permission mode, and any allowedPrompts.
  4. Marks plan mode as exited, closes the dialog, and calls toolUseConfirm.onReject() specifically to unblock the current query loop. This is control flow, not a semantic “user rejected the plan.” See src/components/permissions/ExitPlanModePermissionRequest/ExitPlanModePermissionRequest.tsx:340.

What Happens After That The REPL sees the pending initialMessage. Because clearContext is true, it:

  1. Saves the current plan slug.
  2. Calls clearConversation(...).
  3. Resets the displayed messages, read-file state, discovered skills, nested memory paths, bash tool tracking, session title state, and session caches.
  4. Resets cwd to the original cwd.
  5. Clears session metadata and regenerates the session id.
  6. Preserves background tasks, but kills/removes foreground tasks marked isBackgrounded === false.
  7. Restores the old plan slug into the new session so getPlan() still finds the same plan file.
  8. Applies the chosen permission mode and allowed prompt rules.
  9. Sends the initial user message directly to onQuery(..., shouldQuery=true), so the model immediately starts implementing the plan in the cleared conversation.

That restart path is in src/screens/REPL.tsx:3037, and clearConversation does the actual clearing/session regeneration in src/commands/clear/conversation.ts:109 and src/commands/clear/conversation.ts:203.

Important Details The user-visible message after the clear renders as a plan card labeled “Plan to implement”, because planContent causes the UI to render the plan instead of the raw Implement the following plan... text. That rendering path is src/components/messages/UserTextMessage.tsx:42.

The normal ExitPlanModeV2Tool.call() success result is not used on the clear-context path. The clear path rejects the pending tool use and starts a fresh query instead.

I also don’t see setNeedsPlanModeExitAttachment(true) being called in this clear-context branch. The fresh implementation turn relies on the explicit Implement the following plan: prompt rather than the normal plan_mode_exit attachment/tool-result flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment