fix exit_plan_mode ignoring policy `allow` decision when scheduler skips confirmation

[backnotprop]

Problem

When a user policy grants decision = "allow" for exit_plan_mode, the scheduler's _processToolCall() correctly skips the confirmation phase (no TUI dialog). However, this also means shouldConfirmExecute() is never called, so approvalPayload remains null.

When execute() runs, approvalPayload is null and falls through to the rejection branch, returning "Rejected (no feedback)" — even though the policy explicitly allowed execution.

The existing ALLOW handling inside shouldConfirmExecute() (which sets approvalPayload = { approved: true, approvalMode: DEFAULT }) only runs when the tool itself checks policy via the message bus. It does not run when the scheduler checks policy and skips confirmation entirely.

Expected behavior

When a user policy grants allow for exit_plan_mode, the tool should approve the plan with DEFAULT mode — consistent with the ALLOW branch inside shouldConfirmExecute().

Reproduction

1. Create ~/.gemini/policies/plan-allow.toml:

[[rule]]
toolName = "exit_plan_mode"
decision = "allow"
priority = 100

2. Enter plan mode, create a plan
3. Model calls exit_plan_mode → returns "Rejected (no feedback)" instead of approving

Use case

User policies that auto-allow exit_plan_mode enable hook-driven plan approval workflows — e.g. routing plan review to a web UI via BeforeTool hooks (see plannotator). The policy bypasses the TUI dialog so the hook becomes the sole approval gate, but the tool itself doesn't honor the bypass.

[jerop]

If the plan is rejected in the web UI, how does it reenter plan mode?

[backnotprop]

@jerop This video is just a simple demo I've been using - but you can see nothing happens (stays in plan mode), and my desired ux /use case is structured around to stay within the plan mode so that you can have constant feedback and iteration around annotations.

gemini-discord.mp4

How plan rejection keeps the agent in plan mode

When the BeforeTool hook returns {"decision": "deny", "reason": "..."}, the tool execution is blocked — exit_plan_mode never runs. Since exit_plan_mode is the only thing that transitions the CLI out of plan mode (config.setApprovalMode()), the CLI stays in plan mode automatically. Nothing changed, so the model is still in plan mode, sees the denial reason as a tool error, and can revise the plan and try exit_plan_mode again.

Flow

1. Model calls exit_plan_mode → BeforeTool hook blocks with deny + feedback
2. Model receives: "Tool execution blocked: Plan rejected by user. Feedback: ..."
3. Model is still in PLAN mode (never left) → revises plan → calls exit_plan_mode again
4. Hook fires again → web UI shows updated plan → cycle repeats until approved

---

An alternative approach would be you all having a hook for permission request dialogs. Across any type of tool, like PermissionRequest(exit_plan_mode) - With approval modes and behavior patterns for rejection feedback and/or approval feedback as well.

When hook is removed, plan remains as expected in TUI

[backnotprop]

You probably need something like this in order to integrate with AntiGravity - I have a lot of users who mention AG's annotation UX & similarities with what i do. It's all hooks-based - btw, my original idea - just to show you that I have some decent idea of trajectory and desired integration across industry

I think planning is going to be especially important as agents become more capable. You might see enterprise workflows around reviewing plans in an automated way for things like governance and security checks before implementation is executed.