[BUG] Windows: Cowork local sessions fail with spawn ENAMETOOLONG once ~400 scheduled tasks exist (--allowedTools exceeds 32,767-char command line limit)

Summary

On Windows, the desktop app builds the claude.exe command line with one --allowedTools path rule per registered scheduled task. Every task ever created contributes a rule — including one-off tasks that already fired and are disabled. Once the total command line crosses the Windows CreateProcess limit of 32,767 characters, every local Cowork session and every scheduled task fails to start with spawn ENAMETOOLONG, and the UI shows "Something went wrong."

Environment

| Item | Value |

|---|---|

| OS | Windows 11 Pro Insider Preview, 10.0.26220 (build 26220), x64 |

| Claude desktop app | 1.25927.0 (MSIX / WindowsApps) |

| Electron / Node | 42.7.0 / 24.18.0 |

| Bundled claude-code CLI | 2.1.221 |

| Affected | Cowork "On your computer" (local) sessions + scheduled tasks |

| Not affected | Cowork "In the cloud" sessions |

Symptom

Something went wrong

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.

Retrying never helps — the failure is deterministic for affected sessions. Both interactive chats and scheduled tasks are hit.

Log output

From %APPDATA%\Claude\logs\main.log:

[error] Session initialization failed for local_515030e7-...: spawn ENAMETOOLONG {

  errno: -4064,

  code: 'ENAMETOOLONG',

  syscall: 'spawn',

  stack: 'Error: spawn ENAMETOOLONG

    at ChildProcess.spawn (node:internal/child_process:441:11)

    at spawn (node:child_process:810:9)

    at DQ.spawnLocalProcess (...\app.asar\.vite\build\index.chunk-lqIQkqGu.js:95:4075)

    at DQ.initialize (...\index.chunk-lqIQkqGu.js:95:9082)

    at new DQ (...\index.chunk-lqIQkqGu.js:95:3375)

    at z9 (...\index.chunk-lqIQkqGu.js:123:172052)

    at Object.H9 (...\index.chunk-lqIQkqGu.js:124:476)'

}



[info] [CycleHealth] Unhealthy cycle: {

  session_id: 'local_85b23514-...',

  scheduled_task_id: 'gaoxiao-news-daily-publish',

  session_type: 'scheduled',

  host_loop_mode: true,

  cycle_health: 'unhealthy',

  had_first_response: false,

  unhealthy_reason: 'initialization_failed',

  error_message: 'spawn ENAMETOOLONG'

}

The sdkOptions after patch block for the same spawn:

executable: 'C:\Users\<user>\AppData\Roaming\Claude\claude-code\2.1.221\claude.exe',

executableArgs: [ length: 0 ],

toolCount: 15,

allowedToolCount: 461,

additionalDirectories: [ 3 folders ]

Root cause

spawnLocalProcess passes the allow-list as a single --allowedTools command-line argument, and the app appends one Read(...) rule per registered scheduled task:

Read(//c/Users/<user>/Claude/Scheduled/<task-id>/**)

These are emitted for all registered tasks regardless of enabled state, so already-fired one-off tasks keep contributing forever. Windows caps a process command line at 32,767 characters (CreateProcess / lpCommandLine); libuv returns UV_ENAMETOOLONG (errno -4064) when the assembled line exceeds it.

Measured on the affected machine

Live local session's claude.exe command line, read via Win32_Process.CommandLine:

| Component | Chars | Share |

|---|---:|---:|

| Total command line | 32,471 | 100% |

| --allowedTools value | 30,680 | 94.5% |

| └ scheduled-task Read(...) rules — 414 rules | 28,007 | 86.2% |

| └ session/plugin/upload dir rules — 10 rules | 1,893 | 5.8% |

| └ artifact rules — 2 rules | 126 | 0.4% |

| └ MCP tool names | ~590 | 1.8% |

| All other flags (--model, --effort, --max-turns, …) | 1,791 | 5.5% |

| Headroom before the 32,767 limit | 296 | 0.9% |

scheduled-tasks.json state: 414 registered tasks — 94 enabled, 320 disabled (307 one-off with fireAt; 317 with lastRunAt).

With 296 characters of headroom, any session that adds a couple of additionalDirectories (each contributing Read(...) / Edit(...) rules) tips over. That is why it looks intermittent: sessions with no extra folders squeak under, sessions with extra folders fail every time.

Confirming the mechanism

Node probe on the same machine, isolating argv length vs. environment size:

--- ARGV length probe ---            --- ENV var size probe ---

argvExtra=32000  -> OK               envVal=32000  -> OK

argvExtra=32700  -> OK               envVal=33000  -> OK

argvExtra=33000  -> ENAMETOOLONG     envVal=50000  -> OK

argvExtra=50000  -> ENAMETOOLONG     envVal=120000 -> OK

The threshold is the 32,767-char command line. Environment block size is not a factor (PATH is 6,387 chars, whole env block ~7 KB). The 121,791-char system prompt is also not a factor — it is passed out-of-band and is byte-identical in sessions that succeed.

Steps to reproduce

1. On Windows, use Cowork "On your computer" sessions.

1. Accumulate a few hundred scheduled tasks over time. One-off tasks are the natural driver (per-post publishing, per-clip renders, day-0/day-1 reminders). They auto-disable after firing but stay registered.

1. Start a local session with two or three additional folders connected.

1. Session initialization fails with spawn ENAMETOOLONG. Scheduled tasks firing in the same state fail identically and retry in a loop.

Tipping point is roughly 400 registered tasks at typical ID lengths (~28 chars → ~69 chars per rule).

Impact

• Silent, unrecoverable failure. The message "Try sending your message again" is misleading — retrying always fails.

• Breaks unattended scheduled runs, which then retry in a loop (10 failed initializations in ~4 minutes in this log).

• Scales with normal, intended usage. Nothing warns the user they are approaching the limit, and nothing connects "Something went wrong" to the number of scheduled tasks.

• Not fixable from the UI without deleting hundreds of tasks one at a time.

Suggested fixes

1. Don't emit path rules for disabled/already-fired tasks. Only enabled tasks need their output folder readable. Here that alone drops 320 of 414 rules — 32,471 → ~10,670 chars.

1. Consolidate the rules. A single Read(//c/Users/<user>/Claude/Scheduled/**) replaces N per-task rules and is functionally equivalent.

1. Pass the allow-list out-of-band — config file, stdin, or env var (the env block has a far larger budget, per the probe above). This removes the bug class entirely.

1. Garbage-collect fired one-off tasks after a retention window, or add a "clear completed tasks" action in the UI.

1. Fail with a useful message. If the assembled command line would exceed 32,767 chars on Windows, say "Too many scheduled tasks / connected folders for this session" instead of surfacing a raw ENAMETOOLONG.

Current workaround

Fully quit the desktop app, then remove entries where enabled === false from:

%APPDATA%\Claude\local-agent-mode-sessions\<accountUUID>\<orgUUID>\scheduled-tasks.json

This drops the command line to ~10,670 chars and resolves the failures.

The app must be fully closed for this to stick — a running app holds the task list in memory and rewrites the file, restoring every removed entry within minutes.