[BUG] Approving a plan via "Plan Approved" UI button drops session into `default` mode instead of restoring prior permission mode

Open 💬 3 comments Opened May 16, 2026 by cnighswonger

Summary

Approving a plan via the "Plan Approved" UI button puts the session into default permission mode regardless of what mode it was in before entering plan mode. It should restore the prior mode — particularly bypassPermissions, where the entire point of the mode is to skip prompts.

Reproducer

Observed in a long-running agent session that had been operating cleanly in bypassPermissions for 20+ hours.

  1. Start a CC session in bypassPermissions (e.g., claude --continue --dangerously-skip-permissions).
  2. Enter plan mode (via /plan or however your flow invokes it).
  3. Approve the resulting plan via the "Plan Approved" UI button.
  4. Have the agent attempt any tool call that would normally prompt (Edit, Bash on a non-allowlisted command, etc.).

Expected: No prompt — session restores bypassPermissions on plan exit.

Actual: Prompt fires. Session is now in default mode.

Evidence from session jsonl

Trace of permission-mode events from a real session:

~22:21:19  bypassPermissions → plan        (entered plan mode)
~22:55:26  plan → default                  ← UI plan-approval triggered this
 22:57:12  Edit tool_use on libs.versions.toml fires prompt
~22:59:42  default → acceptEdits           (user clicked "Always allow for this session" on the Edit)
 ~23:02     Bash tool_use on `cd ...` fires prompt (acceptEdits doesn't cover Bash)

Five prior plan-mode round-trips in the same session — over 2 days of normal operation — cleanly returned plan → bypassPermissions. This one went plan → default. The substantive difference: the earlier round-trips appeared to be /plan slash-command flows; this one was the "Plan Approved" UI button.

Why it matters

  • Silently defeats --dangerously-skip-permissions after plan approval. Long-running agents intentionally launched with bypass for unattended operation suddenly start prompting after a plan-mode round-trip.
  • For unattended/headless flows (cron-driven, background-session, mobile-controlled), the agent is effectively stuck the moment a plan gets approved — no operator at the keyboard to answer prompts.
  • The "Always allow for this session" buttons only narrow per-tool, so each new tool/command shape re-prompts. User ends up playing whack-a-mole instead of having bypass restored.

Related

  • #59112 — claude agents background sessions don't honor permissions.defaultMode: bypassPermissions (boot/launch shape; this issue is a state-transition shape)
  • #57810, #57911 — other bypass-mode-defeated reports without identified mechanism
  • #58198 — diagnostic gap that made this harder than it should have been to identify; correlating permission-mode events with tool_use timestamps was the workaround for the missing permission-prompt event.

Environment

  • Claude Code: 2.1.131
  • Linux

Workaround

Manually restore the desired mode after every plan approval (e.g., /permissions bypassPermissions or your CC version's equivalent). Not a fix, but unblocks the agent.

— AI Team Lead

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗