spawn ENAMETOOLONG in Cowork on all chats (new, existing, empty) - Windows 10 Build 26100

[abigailcjs]

Preflight Checklist

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

What's Wrong?

Every Cowork session fails immediately with spawn ENAMETOOLONG — affects new chats, existing chats, and brand-new empty chats. Error fires before any message content is sent.

Environment:

• Claude Desktop: 1.15962.1.0
• Claude Code CLI: 2.1.176 (C:\Users\CSCHORR.local\bin\claude.exe)
• Windows 10 Build 26100
• PATH length: 1,771 characters

Steps to reproduce:

1. Open Claude Desktop on Windows 10 Build 26100
2. Open Cowork tab
3. Start any chat (new or existing, even empty)
4. Error fires immediately: spawn ENAMETOOLONG

Notes:
PATH length of 1,771 characters is above average and may be contributing to pushing the spawned command past Windows' ~8,191 character CreateProcess limit when combined with Cowork's system prompt and model string. This matches the pattern reported in #60669 where the issue was account-specific rather than machine-specific.

Related issue: #60669

What Should Happen?

just work

Error Messages/Logs

Try sending your message again. If it keeps happening, share feedback so we can investigate.

spawn ENAMETOOLONG
You can restart the conversation from an earlier message.

Steps to Reproduce

every cowork attempt

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.176 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[vitoraragao1]

I hit the same spawn ENAMETOOLONG on Cowork Desktop (Windows 11, same MSIX package Claude_pzs8sxrjxfjjc). It fired on every chat including brand new empty projects, while normal chats outside Cowork and claude --print kept working. I traced it on my own machine, and I think it explains the Pro vs Max behavior in this thread without needing an account specific backend bug.

TL;DR

The Desktop app builds the session worker's environment block with a variable, CLAUDE_CODE_WORKSPACE_HOST_PATHS, that holds one directory path per installed plugin. The plugin list lives on the server and is re synced on every app launch, so it is per account, not per machine. Enough accumulated plugins push the total environment block past the Windows CreateProcess limit (32,767 chars), and every session spawn fails.

Why this explains Pro vs Max

A brand new Pro account has zero plugins, so its environment block is small and Cowork spawns fine. An older Max account that has accumulated plugins carries all of those paths into the environment block. Same machine, same app, same install. The only variable that actually changes is how many plugins the signed in account has synced. That is why it looks account specific, but the real driver is plugin count, not a broken backend.

It is the sum, not one variable

I want to be precise here, because it is easy to overstate:

• At a peak of 85 plugins (MEASURED: the app logs [length]: 85 right before the failed spawn), CLAUDE_CODE_WORKSPACE_HOST_PATHS was about 15,362 chars (ESTIMATED: 180 chars per path times count).
• That alone does not exceed the 32,767 limit.
• The overflow is the sum of all 60 environment variables (MEASURED count) in the spawn block. The OAuth JWT (CLAUDE_CODE_OAUTH_TOKEN) and the Cowork memory index (CLAUDE_COWORK_MEMORY_INDEX_CONTENT) also weigh in.
• Plugins are simply the one component that grows without bound over time, until the total crosses the cap.

Measurements

All values are from the affected machine. Each is marked MEASURED (read from log or disk) or ESTIMATED (computed from measured values).

Item	Value	Source
Plugin count at peak	85	MEASURED (log [length]: 85)
Plugin count after cleanup	3	MEASURED (disk)
Length of each plugin path (virtual, in env block)	180 chars	MEASURED (log)
Length of the skills-plugin path	158 chars	MEASURED (log)
Physical on disk path length (not used in env block)	227 chars	MEASURED (disk)
Number of variables in the spawn env block	60	MEASURED (log)
WORKSPACE_HOST_PATHS size at peak	~15,362 chars	ESTIMATED (length x count)
WORKSPACE_HOST_PATHS size now	~520 chars	ESTIMATED (length x count)
Total env block size	> 32,767 chars	MEASURED indirectly (spawn failed)
Total env block size (exact)	not measured	log records names, not values

The virtual path is 180 chars while the physical disk path is 227 chars. The difference is the MSIX virtualization prefix. The environment block uses the virtual representation, so 180 is the number that matters.

Two behaviors that make it worse

1. Deactivating plugins only in the Desktop app does not persist. They come back on the next server sync (I saw them return in under an hour). The durable fix has to be done on the web.
2. The local per session plugin folder never auto cleans. ...\local-agent-mode-sessions\<id>\<id>\rpm accumulates one subfolder per plugin and keeps orphans of deactivated plugins until you rebuild it manually.

Workaround that worked for me (order matters)

1. Go to claude.ai in the browser, Settings / Customize, Plugins, and deactivate everything you do not use.
2. Fully quit Cowork Desktop (confirm no Claude process remains in Task Manager).
3. Rename the session rpm folder (rename, do not delete, so it is reversible).
4. Reopen Cowork and send any message to trigger a clean re sync. The app rebuilds rpm with only the active plugins.
5. Verify the new count. Mine dropped from 28 to 3:

(Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\<id>\<id>\rpm" -Directory).Count

Doing step 3 before step 1 only gives temporary relief. The server still pushes the full list, so rpm re accumulates on the next sync. Web first, then rpm.

Locally installed custom .plugin files (outside the session folder) are outside the sync cycle and are safe. Do not touch them.

Suggested root fix (Anthropic side)

In order of impact:

1. Do not pass the plugin path list (or other large payloads like the memory index) via the environment block / argv. Deliver it through a temp file by reference, stdin, or a manifest the worker reads. This removes the only unbounded growth component from the env block and kills the whole class of failure on Windows.

   There is a strong precedent for this exact fix on this exact error. The nexu-io/open-design project hit the same spawn ENAMETOOLONG (Windows) and spawn E2BIG (Linux) when a Claude Code subprocess embedded a large payload in argv, and their fix history is useful here:

   • Platform limits, as documented in their fix nexu-io/open-design#143: on Linux, MAX_ARG_STRLEN is about 128 KB per argv entry and overflows as E2BIG; on Windows, the CreateProcess command line cap is about 32 KB directly, but only about 8 KB when invoked through a .cmd shim, overflowing as ENAMETOOLONG. That .cmd shim detail likely explains why some reports cite ~8,191 and others ~32,767.
   • They first shipped a temp-file fallback (#97), then judged it inferior (left a stray file, did not cover Linux, was slower) and moved to stdin delivery as the final fix (#143), with a regression test asserting the payload never lands in argv even at 200 KB.

   The same move applies here: get the large, unbounded payload off argv / the environment block and onto stdin or a file reference.

2. Include only active plugins in the env block. In my case the variable carried 85 paths while only a fraction were active. Filtering to active plugins would shrink it from about 15,362 chars to a few hundred, which by itself would have prevented the overflow.

3. Auto clean the rpm folder by removing subfolders for plugins no longer in the active list, instead of accumulating orphans.

4. Catch ENAMETOOLONG at spawn and show an actionable message pointing at plugin count and the web fix, instead of the generic "Something went wrong."

Self check diagnostic for other affected users

If you are hitting this, paste the block below into Claude Code (or run the PowerShell yourself) to confirm whether plugin accumulation is your cause. It is read only: it measures and reports, and does not delete or modify anything.

I'm getting "spawn ENAMETOOLONG" in Claude Cowork Desktop on Windows. It happens on
every chat, including brand-new empty projects, while normal chats outside Cowork and
`claude --print` work fine. I want to confirm whether the cause is plugin accumulation
inflating the spawn environment block (the CLAUDE_CODE_WORKSPACE_HOST_PATHS variable).

Please do the following diagnosis. Do NOT delete or modify anything, only read,
measure, and report. Mark every number as MEASURED (read from a log/disk) or ESTIMATED
(computed). Do not invent values; if something can't be measured, say so.

1. Confirm the Cowork app data root exists:
   $env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude

2. List every "rpm" folder under "local-agent-mode-sessions" with its full path and
   the number of immediate subfolders (each subfolder = one materialized plugin):
   Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions" -Recurse -Directory -Filter "rpm" -ErrorAction SilentlyContinue |
     ForEach-Object { [PSCustomObject]@{ Path = $_.FullName; SubFolders = (Get-ChildItem $_.FullName -Directory).Count } }

3. For the rpm folder with the most subfolders, measure the character length of the
   full path of a representative plugin subfolder, and report min/max/average across
   its subfolders.

4. Open the app log and find the spawn failure and the plugin count it logged:
   - Look under the Claude app data root for a logs folder or a main.log.
   - Search the most recent log for "ENAMETOOLONG" and show the surrounding lines.
   - Search for a logged plugin array length near the failed spawn (e.g. "[length]:")
     and report the peak plugin count if present.
   - Search for the count of environment variables in the spawn env block and report
     it. The log likely records env variable NAMES but not VALUES, so the exact total
     env-block size may not be recoverable. If so, say it's not measurable, don't
     estimate it as fact.

5. Estimate CLAUDE_CODE_WORKSPACE_HOST_PATHS size as (measured path length x plugin
   count + separators), clearly labeled ESTIMATED, for the peak count (if found) and
   the current count.

6. Verdict: based on the numbers, is plugin accumulation the likely cause? Remember
   this variable usually does NOT exceed 32,767 on its own; it's the sum of the whole
   env block (OAuth JWT, memory index, etc.) that overflows, with plugins being the
   component that grows over time.

Then summarize the fix WITHOUT executing it (I'll do it manually):
- Source of truth is the server (claude.ai), re-synced on every launch. Deactivating
  plugins only in the desktop app does NOT persist. Fix on the web:
  claude.ai > Settings/Customize > Plugins > deactivate everything unused.
- After reducing on the web: fully quit Cowork, rename the rpm folder, reopen, send a
  message to trigger a clean re-sync, then re-count rpm subfolders to confirm it
  dropped. Order matters: web first, then rpm.
- Any locally-installed custom .plugin files (outside the session folder) are outside
  the sync cycle and safe; don't touch them.

Happy to share more detail if it helps narrow down the fix.