claude-code - 💡(How to fix) Fix [BUG] Approving a plan via "Plan Approved" UI button drops session into `default` mode instead of restoring prior permission mode

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Root Cause

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.

Fix Action

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

Code Example

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

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

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING