[FEATURE] Let a PermissionRequest hook approve a plan with the context cleared

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 a plan is ready, Claude Code's own approval dialog offers "Yes, clear
context and use auto mode" as its first option, and with
showClearContextOnPlanAccept turned on that is the option most people want.
The planning conversation gets dropped and implementation starts with just the
plan in context.

A PermissionRequest hook on ExitPlanMode cannot offer that. The decision
object it writes back supports behavior, updatedInput, updatedPermissions
and message, and none of those clear the conversation. So a hook that returns
allow always lands in "keep context", whatever the reviewer wanted.

Both answer paths are live for the same request and the first one to answer
wins, which makes the limitation concrete rather than theoretical. I maintain a
small tool that opens the plan in nvim through this hook. Every time I want the
context cleared I have to ignore my own review window and answer in the CLI
dialog instead, and the hook process and its window are then discarded
mid-review.

Proposed Solution

Either of these would work, and I have no strong preference between them:

Add a clearContext field to the decision object. A hook opts in
explicitly, and a plan-review plugin can offer the same set of choices the CLI
dialog does.

{
  "hookSpecificOutput": {
    "hookEventName": "PermissionRequest",
    "decision": {
      "behavior": "allow",
      "clearContext": true,
      "updatedInput": { "plan": "..." },
      "updatedPermissions": [
        { "type": "setMode", "mode": "auto", "destination": "session" }
      ]
    }
  }
}

Or read showClearContextOnPlanAccept on the hook path. When the setting is
on and a hook allows an ExitPlanMode request, clear the context the same way a
manual approval would. This needs no plugin changes, though it gives the hook no
say per plan.

Alternative Solutions

There is no workaround I can find from inside a hook. Denying the request sends
the plan back to be revised rather than starting a fresh turn, and nothing in
the hook output reaches the session's context handling.

What I do today is let my review window lose the race on purpose: I read the
plan in nvim, switch back to the terminal, and answer in the CLI dialog so I get
the clear-context option. That works, but the review tool then has no way to
know its answer was thrown away.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. I turn on showClearContextOnPlanAccept and install a plan-review hook.
2. Claude finishes planning and calls ExitPlanMode.
3. The hook opens the plan in nvim; the CLI dialog opens at the same time.
4. I want the plan approved with the context cleared, so I have to leave the

review window and answer in the dialog.

1. With clearContext in the decision object I could approve from the review

window and get the same result.

Additional Context

This has come up a few times and I don't think any of the existing issues is
still open for the hook path:

• #25690 asked for a configurable default for the ExitPlanMode menu and

included this same clearContext field as its Option B. A bot closed it for
inactivity and it is now locked, so I can't comment on it.

• #71061 raised the hook-specific version. A bot auto-closed it as a duplicate

of #25690 three days after it was filed, before anyone looked at it.

• #81393 (open) asks for the same "accept, clear context and auto mode" action

on mobile, desktop and claude.ai remote control.

• #71614 (open) asks for a "clear context & implement plan" action in plan mode.

Reading those together, the clear-context action exists only in the terminal
dialog, and every other way of approving a plan is missing it. This request
covers the hook path.

The plannotator maintainer confirmed the same limitation at the source level in
2.1.195 and closed their issue as blocked on Claude Code
(backnotprop/plannotator#967).