[BUG] CLI: permission mode silently changes to acceptEdits without user input

Description

In the terminal CLI, a session's permission mode changes to acceptEdits ("accept edits: on") without the operator having set it. This has occurred many times across sessions.

No Shift+Tab was knowingly pressed. An accidental press cannot be excluded with certainty, but Shift+Tab is not adjacent to key combinations that I regularly use, and the recurrence makes repeated accidental presses an unconvincing explanation.

This is more than an annoyance because the change is in the weakening direction: the default mode (prompt before acting) becomes acceptEdits, so file edits are applied without approval in a session whose operator deliberately runs manual approval. A permission mode that silently relaxes itself is a safety property rather than a cosmetic one.

Steps to reproduce

I do not have a deterministic reproduction and would rather say so than guess at one. What I can report is the condition under which it recurs: ordinary CLI use over long sessions, mode left at the default, no permission-mode key pressed. At some point the footer reads accept edits: on.

I also run several CLI sessions concurrently in separate terminal windows. I mention that as an environment fact rather than a suspected trigger — a large share of users presumably do the same.

Expected behaviour

A session's permission mode changes only when its operator changes it.

Actual behaviour

It changes to acceptEdits on its own.

A hypothesis worth ruling in or out

This setup has auto mode disabled, via "disableAutoMode": "disable" in settings.json, which shortens the shift+tab cycle to default → acceptEdits → plan. If some code path advances the permission mode by one step rather than assigning a specific mode, that configuration would make it land on acceptEdits every time, which is what I observe. If that is the mechanism, the underlying bug would affect anyone whose cycle starts at the default, and disableAutoMode would merely make the destination predictable. I have not verified this — it is offered as something cheap to check in the code rather than as a finding.

Possibly related, none of them the CLI

• #23919 — autocomplete suggestions leaking between concurrent CLI sessions in separate terminal windows (area:tui, has repro, closed as stale). Different piece of state, but it is the one existing report of per-session TUI state not staying per-session in the CLI.
• #27380 — permission mode reverting when switching between concurrent sessions, on the desktop app. Two commenters objected that the bot-proposed duplicates were not duplicates; it was later auto-closed for inactivity and then locked, so a CLI report cannot be added there. There is enough shared code between the desktop app and CLI that it could plausibly have the same cause.
• #36531, #24084, #35822 — the same symptom in the VSCode/Cursor extension, triggered by Ctrl+Tab tab switching. Those are extension-side; this report is the terminal CLI.

Environment

• Claude Code 2.1.263
• macOS 15.3.1 (Darwin 24.3.0)
• Terminal CLI — not the VSCode extension, not the desktop app
• "disableAutoMode": "disable" set in settings.json

---
🤖 Filed with Claude Code