[BUG] System prompt consumes ~9.3M tokens on every session after installing Claude Desktop on Windows (WSL setup)

Looking at the error message, it says that you have 4.5m tokens worth of tools enabled. Try disabling your MCP servers and see if that resolves the problem. If it does, one or both of the MCP servers might be misbehaving

This looks like a useful MCP/tooling-readiness failure mode rather than a normal conversation-size issue. From the public evidence, the next checks I would isolate are:

• count enabled MCP servers and compare the first failing session with all MCP servers disabled
• inspect whether any MCP server exposes unusually large tool schemas or attachment/context payloads
• check whether Claude Desktop added or duplicated a tool source after install
• capture the prompt-size/token estimate before and after disabling each MCP source
• keep WSL, Claude Desktop, and Claude Code config paths separate while testing so the failing source is not hidden by shared config

No private logs or account access needed; this is just a public triage checklist for narrowing the tool/context source.

Hey @CptnFizzbin and @maxim-ultra, thanks for the suggestions.

I actually tried disabling MCP servers early on.. ran with --strict-mcp-config --mcp-config '{"mcpServers":{}}' and the token count didn't budge. Still 4.5M in system tools.

/context breaks it down like this:

• System prompt: 6k tokens (3%)
• System tools: 4.5M tokens (2260.4%)
• Skills: 1k tokens (0.5%)
• Messages: 3.5k tokens (1.7%)

So it's definitely not MCP: or at least not the MCP servers I have registered.

Something else is getting loaded into system tools that I can't see or control from the outside.

Any idea what else could be injecting tool definitions at that scale?

Thanks for checking that. If an empty MCP config still leaves System tools at 4.5M, I would stop treating this as a normal MCP-server schema problem.

The next split I would make is tool source vs. tool duplication:

• try a completely fresh Claude Code config/profile, then compare /context; if fresh is normal, diff only the config/plugin/skill/tool-source paths the broken profile loads
• look for repeated tool names/prefixes rather than one huge tool; 4.5M smells more like registry duplication or a generated schema being re-added than ordinary tool bloat
• isolate Claude Desktop integration/config separately from Claude Code config; since this appeared after Desktop install, the shared tool bridge may be upstream of MCP server registration
• if maintainers can inspect internals, the useful artifact would be a pre-tokenization tool registry summary: total tool count, largest schema size, duplicate tool names, and duplicate source paths

No private logs needed. A redacted /context plus a fresh-profile comparison should narrow whether this is one pathological tool definition or a duplicated tool registry.

Thanks for the suggestion @maxim-ultra!

A fresh profile comparison gave us something concrete:

• Fresh profile + personal account (<redacted>@gmail.com): 15.2k system tools (normal)
• Fresh profile + work account (alton@<redacted>.org): 4.5M system tools (broken)

Same machine, same Claude Code version, same blank profile with zero local config, zero MCP servers. The only variable is the account. So this is definitively server-side and tied to the work account specifically - nothing local is causing it.

Would love to know what's attached to that account server-side that's generating 4.5M tokens of system tools.

Happy to provide any additional info that would help narrow it down.

That profile/account split is strong evidence. At this point I would frame the bug for maintainers as account-scoped server-side tool registry inflation, not WSL, local MCP, or local config.

A tight next diagnostic packet, without exposing secrets, would be:

Known-good control:
- same machine
- same Claude Code version
- fresh profile
- personal account
- /context system tools: 15.2k

Broken variant:
- same machine
- same Claude Code version
- fresh profile
- work account
- zero local MCP servers
- /context system tools: 4.5M

Inference:
- local config is ruled out
- MCP server schemas are very likely ruled out
- likely server-side account/org attachment, duplicated tool registry, connector entitlement, stale tool bundle, or generated tool schema attached to the work account

If Claude Code has any command that emits tool-source identifiers/counts without dumping tool contents, that would be the highest-value artifact now. Something like source -> tool_count -> token_estimate, with names redacted if needed, would let support identify whether this is one gigantic tool source or many duplicated sources.

Until that exists, the most useful public evidence may be a screenshot or pasted /context summary from both fresh profiles plus the exact account type difference. No private tokens, org internals, or full tool dumps needed.

@maxim-ultra no tool-source command exists as far as I can tell -- mcp list just shows the two registered servers, nothing about tool counts or schemas.

Here's the clean diagnostic packet:

Known-good control:

• WSL2 on Windows
• Claude Code 2.1.162
• fresh profile, zero local config
• personal account (claude_pro, individual)
• zero local MCP servers
• /context system tools: 15.2k tokens

Broken variant:

• same machine
• same Claude Code version
• fresh profile, zero local config
• work account (claude_team, my_org)
• zero local MCP servers
• /context system tools: 4.5M tokens

Local config, WSL, MCP server schemas, and Claude Desktop are all ruled out.

The only variable is the account/org.

A fair guess at this point is something attached to my org, but no other members of my org are experiencing this, which probably rules out an org-wide attachment.

It's more likely something specific to my user account within the org -- a connector, entitlement, or tool bundle tied to my account specifically rather than the org itself?

The Desktop install is still the most likely trigger since the timing lines up exactly, even if uninstalling it didn't resolve it. Is there a way to inspect or reset what tool sources are attached to a specific user account?

Following a suggestion to run a proxy to capture the raw API request, here's what I found.

Method:

1. Created a local proxy.js that intercepts requests to api.anthropic.com, writes them to a timestamped JSON file, then forwards them normally.
2. Launched Claude Code with ANTHROPIC_BASE_URL=http://localhost:8000 and sent a single "hi" prompt.
3. What the captured request shows (redacted):

{
  "model": "claude-haiku-4-5-20251001",
  "tools": [
    {
      "name": "Workflow",
      "input_schema": {
        "properties": {
          "script": {
            "maxLength": 524288
          }
        }
      }
    },
    ... (many more)
  ],
  "messages": [
    {
      "role": "user",
      "content": [
        "<system-reminder> ... full Claude Agent SDK docs ... </system-reminder>",
        "hi"
      ]
    }
  ]
}

What this means:

The tool definitions being sent include the full Claude Agent SDK / multi-agent harness: Workflow, orchestration patterns, agent spawning, the works. A single field has a maxLength of 524,288 characters. This is not standard Claude Code tooling. Something attached to my work account is injecting an entirely different and vastly larger tool set on every session that I never explicitly enabled.

Timing still lines up with installing Claude Desktop. My guess is it likely enrolled my account in a multi-agent feature without opt-in.

Is there a way to detach or disable this agent SDK harness from a specific user account?

@maxim-ultra @CptnFizzbin

Looking at your repro, the smoking gun is in your "What I've ruled out" — 9.3M tokens after claude_desktop_config.json propagation, with only 2 MCP servers and small CLAUDE.md files. That ratio (system + tools = 9.3M, actual conversation = 1.3k) almost certainly means one of those MCP servers is exposing a tool schema with a giant inline payload — Figma's MCP is the usual suspect, since file attachments and asset metadata in Figma tools can be encoded into the schema definition itself.

A few things I'd try in order:

1. Disable Figma MCP temporarily (claude mcp remove figma or set disabledMcpServers in ~/.claude/settings.json) and start a new session. If the 9.3M drops, you've confirmed Figma is the source. If it stays at 9.3M, the issue is something else (likely an OAuth-scoped attachment from claude.ai that the Desktop install is injecting, since both are signed in with the same account).

1. Inspect the actual system prompt + tool definitions. I use ccglass (npm i -g ccglass && ccglass claude) for this — it shows the full system prompt, per-tool schema size, and a token breakdown by section. You can see which tool is contributing the most tokens. In your case I'd expect to see one tool definition in the 8-9M range, not 100+ small ones. Also: ccglass has an MCP server, so once it's running you can ask Claude directly "which of your tools has the largest schema?" and it'll tell you from inside the session.

1. Check ~/.claude.json size before and after installing Desktop — the 18-hour delay suggests Desktop is writing a large OAuth-scoped payload asynchronously. If the file size jumps by 8-9MB at some point, you've found it. (du -h ~/.claude.json before and after a few hours.)

1. Compare with a brand-new claude.ai account in a different browser profile. If the issue doesn't repro there, it confirms something Desktop is syncing into the existing account's state.

The 18-hour delay is also telling — this isn't a config change at install time, it's something Desktop writes or refreshes asynchronously in the background (likely a sync of claude.ai attachment metadata or project state).

Worth filing a separate issue with the per-tool schema sizes once you've narrowed it down — that's the actionable version of this report.

Update:

It's working again as of this morning, which strongly suggests something was fixed server-side on my account.

I did get further into the diagnostics using ccglass and a local proxy to capture the raw API request, but by the time we had those tools running the issue had already resolved itself (or Anthropic fixed it) so we were effectively profiling a working session, not the broken one.

The tool registry we captured had 30 tools including Workflow, CronCreate, ScheduleWakeup, DesignSync, Monitor and others that aren't part of standard Claude Code, suggesting the full multi-agent/Ultracode harness was loaded. But since we couldn't capture a request from the broken session, we can't confirm whether that was the actual source of the inflation or just normal for a claude_team account.

The key finding that still stands:

Fresh profile + zero local config + personal account (claude_pro) = 15.2k system tools.

Same setup + work account (claude_team, Codethedream org) = 4.5M system tools.

That should rule out local config, MCP servers, and WSL entirely - whatever it was lived on the account server-side.

Leaving this open for a couple days in case it regresses. Happy to provide diagnostics if it comes back now that I have the proxy and ccglass set up, I can actually capture the broken state next time.

Thank you for taking the time to report this.

Closing as resolved per your confirmation that the account returned to normal system tool sizing on June 17 and has remained stable since. The fresh-profile comparison isolating the inflation to a single account's server-side tool registry was a useful diagnostic.

If the inflated /context numbers reappear on the same account, please open a new issue referencing this one.