Bug: Windows Desktop App token loop with Claude Code/MCP causes immediate 100% session lockout

This is genuinely frustrating, and the lockout-at-15-minutes part is the most under-explained piece, so let me separate what's expected mechanics, what you can act on, and what is a backend bug you can only escalate. I'll flag which parts are officially documented vs inferred.

Why session at 100% while weekly is 51% is consistent (documented). Pro/Max have two independent limits: a 5-hour rolling session limit and a weekly limit. "Resets in 3hr 43min" is the session window refilling, and it's a separate counter from the weekly 51% — so being locked on one while the other is half-full is expected, not a contradiction. (usage & length limits) The "limits shared with Claude Code" line means claude.ai chat, the Desktop app, and Claude Code all draw from one shared pool on Pro — so whatever burns tokens in one surface depletes all of them. (Claude Code on Pro/Max)

What can drain a 5-hour session pool in ~15 minutes. Your trigger contexts (PowerShell output, MCP config, unzipping packages) are exactly the high-token-burn ones:

• Large context re-sent every turn (documented). PowerShell output and unzipped file listings are large and unique, and the whole conversation context is re-sent on each turn — so a few turns carrying tens of thousands of tokens of tool output compounds fast. (usage best practices)
• Connected MCP servers (documented overhead). Every connected MCP server loads its full tool schemas into every message. With several servers that can be many thousands of tokens of fixed tax per turn, before you type anything.
• Orphaned/background processes (plausible, NOT officially confirmed). There are open reports of Claude Code leaving background processes running after a task (e.g. #5545, #19097). Whether a detached process keeps consuming quota isn't documented by Anthropic, so treat this as a suspect to rule out, not a confirmed cause.

What you can do right now (operator-side):

1. Confirm which limit is actually hit: claude.ai → Settings → Usage shows separate progress bars for the 5-hour session and the weekly limit. That tells you if the burn is session-only (a fast-consumption problem) vs weekly (a volume problem).
2. Kill stray processes: Windows Task Manager → look for lingering claude / node processes from Claude Code after you close it, and end them. This rules out the orphaned-process suspect.
3. Cut per-turn token cost: run /compact regularly; disconnect MCP servers you aren't actively using (each one taxes every turn); and instead of dumping full PowerShell output or a whole unzipped listing into the chat, capture it to a file and have Claude read specific line ranges. These directly reduce how fast the session pool drains.

What is a backend bug you can only escalate (not fixable locally). The cross-device "Conversation not found" freeze and the profile locking across all devices are backend sync/cache issues — there are existing reports of Windows Desktop sync corruption (e.g. #28180, #23235). Signing out and back in sometimes clears it, but that's a workaround. For the part where a paid Pro session is driven to 100% by background activity you didn't initiate, that's worth escalating to support@anthropic.com (or keeping this issue open) with your claude --version, the exact trigger steps, and whether you have MCP servers configured — the MCP/background angle is the most likely lever for the "instant 100%" you're seeing, and it's the detail that will let them reproduce it.

If after checking Settings → Usage you find the session pool is being eaten with the app idle (no active turn), that's the strongest evidence of a background loop rather than normal consumption — capture that screenshot, because it's the clearest signal that this is a bug and not just heavy usage.

Thank you @yurukusa for the detailed analysis.
Which limit is hit: Confirmed — 5-hour session limit (100% used), weekly only 51%. Fast-consumption problem.
Stray processes: Session drains even on freshly opened Desktop App — not orphaned processes.
My trigger context: MCP server configuration, Amazon SP-API planning, skill-building with tables. No PowerShell output dumped — manual typed chat only.
Key details for backend escalation:

Not using Claude Code CLI at all — Chat tab only
MCP servers connected: GitHub MCP, Gmail, Google Drive, Google Calendar, Filesystem, Windows-MCP, pdf-viewer, Claude in Chrome
Session hits 100% within 15 minutes of fresh chat
Bottom bar shows: "limits shared with Claude Code" — Desktop App activates Code mode in background without user action
Support Conversation IDs: 215474382032800 / 215474589559710

The "Invalid" label is incorrect — this is reproducible, recurring bug on paid Pro account. Requesting Anthropic engineering review of session categorization logic in Windows Desktop App.

Edit: Updated the issue title for clarity. This is a critical synchronization bug affecting paid Pro users utilizing the Windows Desktop Application alongside Claude Code and local MCP servers via PowerShell. The session quota jumps to 100% within 15 minutes despite the backend dashboard displaying only 51% total weekly usage. Please review the backend interaction loops.

CRITICAL UPDATE (June 12, 2026):

This infrastructure defect has just caused a total account and session corruption today. I opened a completely fresh, blank session to bypass the loop bug. Within exactly 5 minutes of standard text interaction, the backend system instantly drained my entire session quota back to 100% (triggering another 4.5-hour lockout) and threw a "Conversation not found" database error.

As a paid Pro user, this ongoing denial of service has completely disrupted my business operations. I have already escalated this via official support channels with a final ultimatum: if this profile corruption and artificial token drain are not manually resolved by a human specialist by June 20, 2026, I will permanently terminate my Pro subscription, remove my corporate credit cards, and file a formal transaction dispute (chargeback) with my bank.

Please unmark this issue from "invalid" and pass it to the core engineering team immediately. The Windows Desktop App / MCP synchronization layer is actively corrupting user session databases.

Update as of July 3, 2026: The June 20 ultimatum in my previous comment has passed with no human engineering response and no resolution. This is now being tracked in parallel under Support Ticket #21547460546069 (separate from the Support Conversation IDs above), with a further escalation sent to Support@Anthropic.com and a final response deadline of July 8, 2026.

Requesting again that this be re-triaged and removed from "invalid" — this is a reproducible backend session/usage tracking defect affecting a paid Pro account, not a Claude Code-specific issue.