Windows: claude.exe argv overflow with large workspaces (CreateProcessW 32K limit)

Issue (upstream Anthropic): claude.exe Windows argv overflow with large workspaces

Target: Anthropic Claude Code repo (@anthropic-ai/claude-code)
Reporter context: OpenClaw multi-agent setup running Claude Code 2.1.119 on Windows 10
Date: 2026-04-27

---

Summary

On Windows, claude.exe (Claude Code CLI) fails with ENAMETOOLONG from CreateProcess when the workspace directory has many top-level entries. The failure is not caused by individual path lengths exceeding MAX_PATH (260) — all paths in the affected workspace stayed under 200 chars. The failure is caused by the argv buffer (~32 KB) of CreateProcess overflowing.

Repro

• Platform: Windows 10 (10.0.19045), Git Bash + native PowerShell, Node 24.14
• Claude Code: 2.1.119
• Setup: workspace directory with 51 top-level entries (mix of .md files and subdirectories), no individual path > 200 chars
• Action: start interactive claude session with cwd set to that workspace
• Result: spawn fails with:

``
spawn ENAMETOOLONG
``
during the inner subprocess invocation that the CLI dispatches as part of context discovery.

When the same workspace is reduced to 18 top-level entries (using NTFS hardlinks for files and junctions for subdirs that point back to the full workspace), claude.exe starts normally and runs without issue.

Why we believe it's argv overflow, not path length

1. Longest absolute path in the affected workspace measured at 177 chars — well below MAX_PATH=260.
2. LongPathsEnabled = 0 in the registry; enabling it does not change the failure mode (this was tested with synthetic 262-char cwd — fails for a different reason, namely Win32 cwd > 260, but that error message differs).
3. Reducing the count of top-level entries (without shortening any individual path) makes the failure go away — strongly implying argv length, not path length, is the binding constraint.
4. Windows CreateProcessW rejects argv buffers > ~32,767 chars (lpCommandLine documented limit).

Impact

• Multi-agent orchestrators that share a single root workspace across many agents (each contributing files/subdirs) hit this consistently on Windows.
• Forces users to fragment their workspace artificially (slim workspace with hardlinks/junctions) to keep top-level entry count low.
• Linux/macOS not affected (much higher argv limits — typically ARG_MAX ≥ 128 KB, often megabytes).

Suggested fix

The CLI appears to enumerate workspace files and pass references via argv to an internal subprocess. On Windows, when the resulting argv would exceed a threshold (e.g. 16 KB to leave headroom), one of the following:

• Option A (preferred): pass the file list via a temp file (--manifest <path>) or stdin instead of argv.
• Option B: use Windows-specific \\?\ prefixed paths and rely on the larger argv limit some APIs allow (CreateProcessW with explicit Unicode env block, etc.) — partial mitigation only.
• Option C: truncate/chunk the workspace enumeration when argv pressure detected, with a warning to the user.

Option A is consistent with how other CLIs (git, rg) handle very large file lists.

Workaround (current)

Slim workspace with NTFS hardlinks/junctions reflecting the real workspace, exposing only ~15-20 top-level entries to claude.exe. Documented at ~/.openclaw/workspace-kim-cli/WORKSPACE_STRUCTURE.md.

References

• Microsoft CreateProcessW: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw — argv (lpCommandLine) limited to 32,767 chars.
• Reproducible in our environment in 100% of attempts before slim workaround; 0% after.