[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](https://claude.com/claude-code)

Start by tracing terminal CLI permission-mode state changes and Shift+Tab handling, then inspect how disableAutoMode in settings.json affects the cycle. Reproduce with concurrent sessions if possible and verify that the mode changes only after explicit operator input, including when auto mode is disabled.

Written by the indexing model from the issue text.