Windows: every Cowork local session fails with spawn ENAMETOOLONG; new empty chats affected and plugin removal is reverted by marketplace re-sync

Status Closed — duplicate
Reported on v2.1.217
Maintainer reply None cached
Activity 1 comment · opened Jul 24, 2026 · closed Aug 25, 2026

Summary

On Windows, every Cowork local session in an affected workspace fails to start with spawn ENAMETOOLONG.
A brand-new, empty chat (single message "Hi") fails identically to an old one, so the account is
effectively unusable. The assembled claude.exe command line exceeds the Windows 32,767-char limit.

Worse, the only remediation a user can discover — removing plugins — is silently reverted by
marketplace re-sync, so the problem appears immune to every fix attempt.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.28120 |
| Claude desktop | 1.24012.1.0 (Claude_1.24012.1.0_x64__pzs8sxrjxfjjc) |
| Claude Code binary | 2.1.217 |
| Plugins | 157 on disk, 113 passed to SDK |
| Marketplaces | 5 (knowledge-work-plugins, life-sciences, claude-for-financial-services, claude-tag-plugins, claude-for-legal) |

Error

[error] Session initialization failed for local_…: spawn ENAMETOOLONG
{ errno: -4064, code: 'ENAMETOOLONG', syscall: 'spawn' }
    at ChildProcess.spawn (node:internal/child_process:441:11)
    at zQ.spawnLocalProcess (…/index.chunk-DwT2CckN.js:100:2244)
    at zQ.initialize (…/index.chunk-DwT2CckN.js:100:7279)
    at async Ve.doSessionInitialization (…/index.chunk-Dep9JkG_.js:199:45562)

Repeats indefinitely; lifecycle flips initializing → idle, [CycleHealth] Unhealthy cycle loops.
User-facing UI shows only spawn ENAMETOOLONG with "Try again", which never succeeds.

Measured cause

Command line of a succeeding session, read via Get-CimInstance Win32_Process:

| Component | Bytes |
|---|---:|
| --plugin-dir × 112 | 20,832 (186 each) |
| --allowedTools | 395 |
| everything else | 440 |
| Total | 21,667 (under 32,767 → spawns) |

Failing sessions carry the same 112–113 --plugin-dir args, but --allowedTools is enumerated from the
session's enabledMcpTools, which is 23,669 bytes:

20,832 (plugin-dirs) + 23,669 (--allowedTools) + 440 = 44,941  vs limit 32,767  → ENAMETOOLONG

Discriminator: the session that works was spawned with --allow-dangerously-skip-permissions, so its
--allowedTools collapses to 395 bytes. Without that flag the full tool allowlist is spelled out on argv.
Same plugins, same connectors — only the permission mode differs.

enabledMcpTools is workspace-global and not user-clearable

Two session records, one an 11-hour-old broken session and one a brand-new empty chat:

| field | new chat | old session |
|---|---:|---:|
| enabledMcpTools | 23,669 | 23,669 |
| pluginInstallPaths | 20,461 | 20,461 |
| projected cmdline | 44,941 | 44,941 |

Identical. A fresh session is born over the limit. Additionally:

  • Editing the session JSON to clear the field is overwritten — the app regenerates the record on each open attempt.
  • Disabling remote connectors (15 → 9, remoteMcpServersConfig 335,265 → 143,558 bytes) left enabledMcpTools at exactly 23,669. remoteMcpServersConfig is not on the command line at all, so connector changes cannot help.

Plugin removal is reverted by marketplace re-sync

The user disabled dozens of plugins over several hours. Observed counts before vs after:

Passing 112 plugin(s) to SDK   →   Passing 113 plugin(s) to SDK
157 plugin dirs on disk (up from 156)

The count went up. Marketplaces re-download and re-register removed plugins, so the one remediation a
user can find silently undoes itself. Only removing the marketplace subscription stops it.

Impact

A user with several marketplaces subscribed and per-tool permissions enabled cannot open any local
session, including brand-new ones, and no action available in the UI fixes it:

  • removing plugins → reverted by re-sync
  • removing connectors → doesn't touch the command line
  • new session → identical config
  • editing session JSON → overwritten

Suggested fixes

  1. Don't put --allowedTools and --plugin-dir on argv. Write them to a temp file or pipe via stdin. This removes the ceiling entirely and is the real fix.
  2. Pre-flight the command line length. If it would exceed the platform limit, fail with "session config too large (N of 32,767 chars)" naming the dominant contributor, instead of raw ENAMETOOLONG.
  3. Stop infinite retries on a deterministic, non-transient spawn failure.
  4. Let users clear enabledMcpTools. It is workspace-global, survives connector removal, and has no UI surface.
  5. Warn on marketplace scale. Installing 5 marketplaces (157 plugins ≈ 29,000 bytes of argv) silently approaches the limit.

Workaround

Remove the marketplaces (not individual plugins) to stop re-sync. With 0 plugins the command line is
0 + 23,669 + 440 = 24,109, which fits. Roughly 46 plugins can then be re-added
((32,767 − 23,669 − 440) ÷ 186 ≈ 46).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗