[Bug] ExitPlanMode Permission Denied Without UI Prompt—Agent Stuck in Plan Mode

Bug Description
Bug Report: ExitPlanMode Denied Without Approval UI — Agent Stuck in Plan Mode

From: Jordan Dea-Mattson
GitHub: @jordan-of (OrdinaryFolk), @jordandm (personal)
Email: jordan-of@users.noreply.github.com

Problem

When an agent calls ExitPlanMode, it gets "Permission to use ExitPlanMode has been denied" — but the user is never presented with an Approve/Deny button or any UI prompt. The agent is stuck in
plan mode with no way out, and the user has no visible action to take.

The core issue is that "pending" is reported as "denied." The permission system appears to be waiting for user input, but instead of showing a prompt and waiting, it immediately returns a denial
to the agent. The agent then tells the user it was "denied" — which is misleading, because the user never made a choice. The user didn't deny anything; the system never asked.

This means:

• The agent believes the user rejected its plan
• The user has no idea anything was requested
• Both sides are confused about what happened
• The agent may stop trying or suggest workarounds instead of retrying

If the permission is pending user input, the system should either (a) display the prompt and block until the user responds, or (b) queue the request and notify the user. Returning "denied" for a
never-asked question is a bug.

Steps to Reproduce

1. Agent enters plan mode via EnterPlanMode
2. Agent writes a plan to the plan file
3. Agent calls ExitPlanMode
4. Expected: user sees an approval prompt or the tool succeeds
5. Actual: tool is denied, no UI prompt appears, agent reports "Permission to use ExitPlanMode has been denied"

Workaround

Typing "Try now?" or similar text in the chat prompt seemed to unblock it — suggesting the permission system was waiting for user input but not displaying the prompt. The agent eventually received
the approval after the user typed a message.

Diagnostic Evidence

• No hooks block ExitPlanMode in settings.json (checked both project and worktree settings)
• The plan-capture.sh PreToolUse hook only matches ExitPlanMode to capture plan content — it exits 0 and never denies
• No hookify rules target ExitPlanMode
• The folio worktree settings.json has no hooks at all (empty hooks: {})
• The issue occurred on the folio worktree (folio branch) running Claude Code v2.1.81

Impact

The agent is completely stuck — plan mode restricts it to read-only operations, so it can't write code, run scripts, or do anything useful. The only options are:

• User types messages blindly hoping to trigger the pending approval
• /exit and start a new session (losing plan mode context)

This is particularly disruptive in multi-session workflows where the user is managing 4-5 agents across worktrees. The stuck agent gives no indication that it needs attention — it just silently
reports "denied" and waits. The user only discovers the problem when they check on the agent and see it hasn't made progress.

Expected Behavior

Either:

• ExitPlanMode should not require a permission prompt (the user already approved the plan in conversation)
• Or the permission prompt should be visibly displayed to the user so they can approve it
• At minimum: if the permission is pending, report "pending" not "denied" — the distinction matters for agent behavior

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.81
• Feedback ID: 4a1c6d52-7e6e-4c2e-a882-1d74bfd50406

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/jordan_of/.local/share/claude/versions/2.1.81 (expected in multi-process scenarios)\n    at TET (/$bunfs/root/src/entrypoints/cli.js:2724:2174)\n    at fgq (/$bunfs/root/src/entrypoints/cli.js:2724:1318)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-21T14:41:04.884Z"}]