[BUG] Fable desktop-app token-drain

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The Claude desktop app launches Claude Code sessions as its own child processes and auto-restores them on startup. A session left in bypass-permissions mode persists that mode in its restore entry. When the app auto-restores such an entry on a PREMIUM model (Fable 5.1 / Opus 5), the restored process crash-loops on startup and the app respawns it repeatedly — each spawn bills premium overage. There is no visible session and no prompt.

Impact: premium overage billing for sessions never opened. ~$40 of Fable overage on 2026-09-06 (eight sessions batch-restored and respawned across one evening); recurred 2026-09-10 with five phantom Fable processes over the evening, each of which I had to find and kill manually.

What Should Happen?

A session that crashes on restore should not be silently respawned; respawning should stop after the first crash. Premium tokens should never be spent on auto-restored sessions without explicit user action, and there should be a visible session or a prompt before any premium spend.

Error Messages/Logs

Restore entries of the respawned sessions carry priorErrorMark.category:"process_crashed".

On 2026-09-06 the crash marks clustered at 03:11:55–03:12:17Z (an ~8:03 PM local burst), with respawns across the evening (~7:14 PM, the 8:03 burst, ~8:58 PM). Each rogue process was a direct child of the desktop app process (confirmed via Get-CimInstance Win32_Process), carrying --allow-dangerously-skip-permissions --permission-mode auto. No Windows Scheduled Task, Run-key entry, or background daemon was involved.

Steps to Reproduce

1. Pin a workspace folder to bypass-permissions mode: preferences.epitaxyPrefs."epitaxy-folder-permission-mode" -> "bypassPermissions" in claude_desktop_config.json, with account-level bypass opted in.
2. Open sessions in that folder. They launch with --allow-dangerously-skip-permissions --permission-mode auto and persist chromePermissionMode:"skip_all_permission_checks" + permissionMode:"auto" in their restore entry under %APPDATA%\Claude\claude-code-sessions\<account>\<workspace>\local_*.json.
3. Restart the app. Auto-restore revives those entries; on a premium model the restored process crashes on launch (restore entry gets priorErrorMark.category:"process_crashed") and the app respawns it. Each respawn bills premium overage.

Note: changing the folder's permission mode only affects NEW sessions; existing bypass entries keep reviving on each startup until the entries themselves are deleted.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.260

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Desktop app: Claude.exe v1.49585.0.0 (Windows Store MSIX), Code tab; bundled claude-code 2.1.260. OS: Windows 11 Pro 26200.

Affected models: the crash-looping sessions were on premium models — Fable 5.1 (claude-fable-5-1) and one Opus 5 — which is what makes the billing impact significant.

Vulnerable state (directly inspected): the restore store held 151+ premium entries marked live (isArchived:false), all in skip_all_permission_checks + permissionMode:"auto". On 2026-09-06 eight were batch-restored at once, each crashed on startup and was respawned in bursts across the evening.

Evidence grade: the crash-restore loop, the child-process parentage, and the persisted bypass state are directly inspected. What first triggered the batch restore (an app wake vs. an explicit restore-all) is inferred, not confirmed.

Existing controls do not cover this: disabling account-level bypass (bypassPermissionsOptInByAccount / bypassPermissionsGateByAccount -> false) and deleting the live bypass restore entries stops it, but that is a manual workaround discovered only after being billed twice. Even the strongest documented control, permissions.disableBypassPermissionsMode:"disable" in managed settings, only prevents bypass mode from being offered — it adds no crash-loop guard and no premium-spend cap, so the underlying defect remains unaddressed.

Suggested fix directions (any one breaks the loop):

1. Do not auto-restore a session whose last exit was a crash; stop respawning after the first crash.
2. Do not silently auto-restore bypass-permissions sessions on premium models — confirm with the user before spending premium tokens.
3. Gate auto-restore on non-premium models, or require explicit action to resume a premium session.
4. Cap or alert on premium spend from auto-restored (vs. user-opened) sessions.

Core defect: a crashed premium bypass-mode session is respawned in a loop with no user visibility and no spend guard, turning a stale restore entry into open-ended premium billing.

---

Update — 2026-09-11 (recurred on claude-code 2.1.266, after the bypass workaround)

The defect recurred the night of 2026-09-10 → 2026-09-11, after I applied the account-level bypass
workaround described above (bypassPermissionsOptInByAccount / bypassPermissionsGateByAccount → false).
That removed the dangerous-permission half but not the premium billing — and it shows the defect is
broader than the crash-loop framing above.

1. Sessions I explicitly closed are being revived — no crash involved. Five premium claude-fable-5-1

processes were running as direct children of the desktop app (confirmed via Get-CimInstance Win32_Process),
created between 2026-09-10 11:50 PM and 2026-09-11 12:46 AM. All ran --permission-mode auto; none carried
--allow-dangerously-skip-permissions. Each was a session I had ended with /closeout. Clearest case:
session 8a99635b closed out (stop_reason:"end_turn") at 2026-09-11T05:06:23Z; the app then created a fresh
process for it at ~07:46Z (~2.7h later), and its transcript gained nothing after closeout.

1. Premium routing is broader than bypass mode. With bypass disabled, sessions still landed on Fable. In

claude_desktop_config.json: coworkModelAutoFallbackByAccount: true (model auto-fallback) and
autoResumeRateLimit opted in. Premium spend on auto-restored sessions is reachable with no bypass at all.

Net: disabling bypass narrows the danger but not the billing. The core defect generalizes to: the app
revives premium sessions the user has explicitly closed, and bills for it, regardless of permission mode or
crash state. Fix direction 1 above should extend to explicit closeout.

Environment for this recurrence: Claude.exe v1.52386.0.0 (MSIX), bundled claude-code 2.1.266;
Windows 11 Pro 26200.