[BUG]

Bug Report: spawn ENAMETOOLONG on Cowork workspace connection — Windows 11
Posted by: Stefan (MGC Transport) | Claude Desktop v1.9659.2.0 | Windows 11

The Error
Every time I attempt to connect a local workspace folder to Cowork, the app immediately throws:
spawn ENAMETOOLONG
The error fires on every attempt without exception — new tasks, existing tasks, empty tasks. Cowork is completely non-functional for me as a result.

My Environment

OS: Windows 11
Claude Desktop version: 1.9659.2.0
Install path: C:\Program Files\WindowsApps\Claude_1.9659.2.0_x64__pzs8sxrjxfjjc\app\Claude.exe
Workspace folder I am trying to connect: C:\Claude (10 characters — not the source of the problem)
Account type: Pro

What I Tried

Enabled Windows long path support via registry — ran the PowerShell command to set LongPathsEnabled = 1 in HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. Applied multiple times across multiple sessions and rebooted after each attempt. No change.
Reduced folder depth inside C:\Claude — removed nested directories and node_modules folders to reduce overall file count and path depth inside the workspace. No change.
Verified the workspace path length is not the issue — C:\Claude is 10 characters, well within any limit. The problem is not the folder I am pointing to.
Attempted multiple Cowork sessions — new sessions, existing sessions, empty sessions. The error fires every time regardless.

Root Cause — Based on Research
After investigating, this is not a user-fixable problem. The issue is that Cowork constructs a subprocess command that includes a large system prompt as a command-line argument. On Windows, the CreateProcess API has a hard limit of approximately 8,191 characters for a spawned command. The combined length of the Claude install path, command flags, and system prompt exceeds this limit.
The Windows long path registry fix does not affect this limit. That fix only addresses file path length, not command-line argument length. No local configuration change resolves this.

Current Status
Cowork is completely unusable on my machine. I have exhausted all suggested workarounds. This requires a fix on Anthropic's side — specifically, the system prompt should not be passed as a command-line argument. It should be written to a file and passed by reference, or handled through another mechanism that does not hit the Windows CreateProcess character limit.

Request
Please prioritize a fix for Windows users. This is a blocking issue that makes Cowork entirely inaccessible.

Same issue on Windows 11, Claude Desktop (latest version, MSIX from claude.com/download), Max plan.

Every Cowork chat throws "spawn ENAMETOOLONG" immediately on send — new chats, empty chats, any model, any selected folder. Cowork is completely unusable on this account.

Already tried (none resolved it):

• Full app restart
• Sign out / sign in
• Switching to every available model before sending
• Using a brand-new folder
• Cleared Cowork global instructions (they were already empty)
• PATH length is short and normal (~480 chars), AppData is on local C:, no redirection
• No vm_bundles / claude-code-vm / local-agent-mode-sessions folders exist under %LOCALAPPDATA%

Regular Chat works fine on the same account/app. This looks like the same account-side model_config issue described in this thread. Please prioritize a fix.

try removing all skills and plug ins

On Tue, Jun 2, 2026 at 11:01 AM Kogi82 @.***> wrote:

Kogi82 left a comment (anthropics/claude-code#60669) <https://github.com/anthropics/claude-code/issues/60669#issuecomment-4603696359> Same issue on Windows 11, Claude Desktop (latest version, MSIX from claude.com/download), Max plan. Every Cowork chat throws "spawn ENAMETOOLONG" immediately on send — new chats, empty chats, any model, any selected folder. Cowork is completely unusable on this account. Already tried (none resolved it): - Full app restart - Sign out / sign in - Switching to every available model before sending - Using a brand-new folder - Cleared Cowork global instructions (they were already empty) - PATH length is short and normal (~480 chars), AppData is on local C:, no redirection - No vm_bundles / claude-code-vm / local-agent-mode-sessions folders exist under %LOCALAPPDATA% Regular Chat works fine on the same account/app. This looks like the same account-side model_config issue described in this thread. Please prioritize a fix. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/60669?email_source=notifications&email_token=CDIOLDAIZMXVIFTBR4BGMTT453T4XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRQGM3DSNRTGU42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4603696359>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CDIOLDD7DF6SA2P6ECTEYJD453T4XAVCNFSM6AAAAACZE7MTH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMMBTGY4TMMZVHE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CDIOLDFBRNYCGII45RHAAE3453T4XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRQGM3DSNRTGU42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CDIOLDHRT7J5P4WSVAEPPJD453T4XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRQGM3DSNRTGU42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

I had this issue over the last few days. This morning I decided to move the Claude folder to the recommended area (there is an option in settings). This fixed it for me.

I am the owner of JK Consultants, a Team account subscriber. We onboarded our entire team and Cowork went down the following day. We have now been down for 3+ days across all Windows machines on our team. Every machine throws spawn ENAMETOOLONG immediately on any Cowork session. We are on Windows 11, latest Desktop App version, Jk_Consultants Team org. Anthropic support has only responded with the Fin AI bot — we have not received a human response or any fix timeline. This is a paid Team account with active business disruption. Requesting direct engineer attention and a fix timeline.

Relates to Issue #60669
Additional data point — same spawn ENAMETOOLONG, different trigger (plugin/skill surface), with a confirmed workaround

Hit the identical spawn ENAMETOOLONG-on-every-Cowork-turn error on Windows, but in my case the trigger wasn't the model-config string — it was the size of the loaded extension surface. Sharing because it points at the same root: the Cowork subprocess command line exceeding Windows' CreateProcess limit.

What happened

• Cowork worked fine with my baseline of ~69 enabled plugins.
• I installed a large third-party skill/plugin bundle into the workspace (~271 skills + 67 agents + a root .mcp.json / .claude-plugin/marketplace.json).
• It kept working until the next full restart — Cowork only scans for skills/plugins at startup. On the next launch it loaded the bundle on top of the baseline, and from then on every message (even a 2-character "No") threw spawn ENAMETOOLONG.
• Fix that worked: remove the bundle from the workspace and fully quit + relaunch the desktop app (closing the window alone isn't enough — the bloated set stays in memory). Back to normal immediately.

Why this is relevant to this issue
It shows the failure scales with the aggregate of plugins/skills/agents/MCP tools serialized into the spawned command, independent of (and additive to) the malformed [1m] model string reported here. Both inflate the same command line; either can push it over the limit.

Suggested fix for the team
Pass the Cowork subprocess config via a file or stdin rather than argv, so command-line length doesn't scale with the number of enabled extensions (and isn't sensitive to stray characters in the model id).

Environment

• OS: Windows 11 Pro (build 10.0.29610)
• claude-code engine: 2.1.181
• Desktop app: <FILL IN — Help/About>
• Account tier: <FILL IN — Pro/Max/Team>
• Enabled plugins at time of failure: ~69 baseline + a ~338-component bundle

Another Windows repro — confirmed [1m] artifact present, plus the command-line-length mechanism

Hitting the same spawn ENAMETOOLONG on every Cowork turn (Windows 11 Pro, build 10.0.29610; claude-code engine 2.1.181). I can confirm the malformed [1m] model-string artifact this issue suspects — it's present throughout my configs:

• ~/.claude.json → claude-fable-5[1m]
• per-session configs → claude-opus-4-7[1m], claude-sonnet-4-6[1m], claude-opus-4-6[1m]

([1m] is an ANSI bold escape with the ESC byte stripped — the "1M context" variant tag leaking into model identifiers.)

The length mechanism, with numbers: the per-session config the desktop app spawns from
(%APPDATA%\Claude\local-agent-mode-sessions\…\.claude\.claude.json) is ~35–36 KB,
which is already at/over Windows' 32,767-char CreateProcess command-line limit. Breakdown:

• cachedGrowthBookFeatures: ~20.7 KB (server-pushed feature-flag cache)
• pluginUsage: ~6.3 KB (number of enabled plugins)
• everything else: small

So two independent factors push the spawned command line over the limit: (a) the [1m]
artifact, and (b) the config size, which scales with the GrowthBook cache and the number of
enabled plugins. Reducing enabled plugins is a partial workaround (buys headroom); it isn't a fix.

Repro/observations

• Fails on empty input (a 2-char message), ruling out chat content.
• Temporarily disappears after a full quit+relaunch, then recurs.
• Installing a large skill/plugin bundle into the workspace makes it fail hard and consistently

(extra surface → way over the limit); removing it + full restart restores it.

Suggested fix: pass the Cowork subprocess config via a file/stdin rather than argv, so
command-line length doesn't scale with enabled extensions or the GrowthBook cache — and sanitize
ANSI codes out of model identifiers so [1m] never reaches the spawned command.

Environment

• OS: Windows 11 Pro (build 10.0.29610)
• claude-code engine: 2.1.181
• Desktop app: <FILL IN — Help/About>
• Account tier: <FILL IN — Pro/Max/Team>

#60669 Cowork throws "spawn ENAMETOOLONG" on every turn, even a 2-char message. Windows 11, desktop app 1.14271.0.0. Logged in main.log: "Session initialization failed for local_…: spawn ENAMETOOLONG" at spawnLocalProcess / doSessionInitialization. Root cause matches issue #60669: the per-session config the app spawns from (%APPDATA%\Claude\local-agent-mode-sessions\…\.claude.json) is ~35 KB — over Windows' 32,767-char command-line limit — and a malformed "[1m]" model tag (e.g. claude-opus-4-7[1m]) tips it over. Please pass the subprocess config via file/stdin instead of argv, and strip ANSI/"[1m]" from model ids. Workaround that helped: remove large plugin bundles, reduce enabled plugins, full restart.

This is a bug issue, the best workaround is Go to Cowork Tab > Customise > Plugins > Disable All Plugins which are not required.

I disabled most as I didn't need them

Agreed. I used Claude Code to help me get through the issue. Reached the same conclusion, and I did disable a lot of plugins.

Thanks.

Wayne C. Correll
Director of Purchasing
Kansas City Kansas Public Schools
Phone: (913) 279-2270
Fax (913) 279-3253
www.kckps.org<http://www.kckps.org>
________________________________
From: kaz00786 @.*>
Sent: Tuesday, June 23, 2026 4:33 AM
To: anthropics/claude-code @.*>
Cc: waynecorrell-creator @.>; Comment @.>
Subject: [CAUTION: NOT FROM USD500] Re: [anthropics/claude-code] [BUG] (Issue #60669)

[https://avatars.githubusercontent.com/u/147075261?s=20&v=4]kaz00786 left a comment (anthropics/claude-code#60669)<https://github.com/anthropics/claude-code/issues/60669#issuecomment-4777792735>

This is a bug issue, the best workaround is Go to Cowork Tab > Customise > Plugins > Disable All Plugins which are not required.

I disabled most as I didn't need them

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/60669?email_source=notifications&email_token=CBWHEMZOTHQPCXDAMV4OCLL5BJFGTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZXG43TSMRXGM22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4777792735>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CBWHEM7HMRNXK34UTQVXCYT5BJFGTAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TINBYGA4TGNRXGI4KC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CBWHEM6SZJGLOOKESKR7U7T5BJFGTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZXG43TSMRXGM22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/CBWHEM5MJ2VUEHBOKT5XMX35BJFGTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZXG43TSMRXGM22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today!
You are receiving this because you commented.Message ID: @.***>

--
This message has been sent from the Kansas City, Kansas Public Schools. The
information contained in this email and any attachments may be privileged
and confidential, and are intended only for the individual or entity
identified as the addressee. If you are not the addressee, or if the
message has been addressed to you in error, you are not authorized to read,
retain, copy, or distribute the message or any attachments. If you have
received the message in error, please delete it and any attachments and
notify the sender by return e-mail or by telephone. Thank you.

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.

1. 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.
2. Auto clean the rpm folder by removing subfolders for plugins no longer in the active list, instead of accumulating orphans.
3. 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.

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.

Thanks for the detailed analysis and the clear reproducible workaround. This matches my situation exactly!

I’m on the Max plan and currently have 104 plugin subfolders in one rpm directory and 95 in another. Both machines throw spawn ENAMETOOLONG on every Cowork chat (including brand-new empty projects) while normal claude --print works fine. Your breakdown of how CLAUDE_CODE_WORKSPACE_HOST_PATHS plus the rest of the environment block exceeds the Windows CreateProcess limit is spot on, and it explains the Pro vs Max difference without needing a backend bug

I’ll run the fix in the order you specified when I have some time and report back with the before/after counts once I have the bandwidth. Really appreciate you tracing this and writing it up so thoroughly!

Adding another repro data point:

OS: Windows 11 [25H2 OS Build 26200.8655]
Claude Desktop version: [1.18286.0.0]
Account type: [Team]
Tab affected: [Cowork]
Workspace path: [C:\Users\cbaird\Claude — short path, so path length isn't the cause]
Behavior: spawn ENAMETOOLONG fires immediately on [every task / new tasks only], no files read or written. Don't need to look up files or work in folder, just chatting causes the error.
Already tried: LongPathsEnabled registry fix + reboot (no change), clean reinstall (no change)

Adding another repro data point: OS: Windows 11 [25H2 OS Build 26200.8655] Claude Desktop version: [1.18286.0.0] Account type: [Team] Tab affected: [Cowork] Workspace path: [C:\Users\cbaird\Claude — short path, so path length isn't the cause] Behavior: spawn ENAMETOOLONG fires immediately on [every task / new tasks only], no files read or written. Don't need to look up files or work in folder, just chatting causes the error. Already tried: LongPathsEnabled registry fix + reboot (no change), clean reinstall (no change)

Follow this please:

Workaround that worked for me (order matters)

Go to claude.ai in the browser, Settings / Customize, Plugins, and deactivate everything you do not use.
Fully quit Cowork Desktop (confirm no Claude process remains in Task Manager).
Rename the session rpm folder (rename, do not delete, so it is reversible).
Reopen Cowork and send any message to trigger a clean re sync. The app rebuilds rpm with only the active plugins.
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.