PR #71617: fix(claude-cli): pass system prompt as file path to avoid Windows ENAMETOOLONG (#71600)

• Repository: openclaw/openclaw
• Author: hclsys
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/71617

Description (problem / solution / changelog)

Closes #71600.

Bug

On Windows, Claude CLI sessions die with spawn ENAMETOOLONG whenever the OpenClaw-injected system prompt + workspace context exceeds the ~32,767-character argv limit. Reporter saw this at ~41k chars in a typical workspace — completely deterministic for Windows users with non-trivial workspace context. Linux/macOS don't impose this OS-level limit so the bug is Windows-specific.

Reporter verified hot patch: write the prompt to a temp file and pass --append-system-prompt-file <path> instead of --append-system-prompt. Resumed 44.7k-prompt sessions immediately.

Fix

Claude Code CLI 2.x already supports the file-based counterpart --append-system-prompt-file <path>. OpenClaw already had a temp-file writer (writeCliSystemPromptFile) for the Codex-style TOML-config-override path. This PR generalizes it for Claude's flag-pair shape:

• src/config/types.agent-defaults.ts — add systemPromptFileArg to CliBackendConfig. Documented as the file-arg sibling of existing systemPromptArg (inline) and systemPromptFileConfigKey (TOML).
• src/agents/cli-runner/helpers.ts —
  • writeCliSystemPromptFile: write temp file when EITHER systemPromptFileArg OR systemPromptFileConfigKey is set.
  • buildCliArgs: new branch that prefers the file-arg pair (flag, path) over inline arg / TOML override when set + file path present. Falls back to inline systemPromptArg if no file path (defense-in-depth so the prompt is never silently dropped on file-write failure).
• extensions/anthropic/cli-backend.ts — wire systemPromptFileArg: \"--append-system-prompt-file\".

This is also a strict improvement on macOS/Linux: writing the prompt to a file avoids re-encoding the same large string on every spawn and keeps it out of process listings (ps aux no longer shows the full prompt). No behavior change for Codex (still uses TOML override), Gemini (still inline), or any backend that doesn't set systemPromptFileArg.

Tests

• new buildCliArgs case: --append-system-prompt-file flag emitted when configured + file path available.
• new buildCliArgs case: falls back to inline arg when file path missing (defense-in-depth).
• new writeCliSystemPromptFile case: temp file written when only systemPromptFileArg is set (Claude CLI shape).
• new writeCliSystemPromptFile case: returns no path when neither file mechanism is configured (Gemini shape).

22 tests pass. Lint clean (pnpm oxlint — 0 warnings, 0 errors).

🤖 generated with assistance from Claude Code Co-authored-by: HCL [email protected]

Changed files

• extensions/anthropic/cli-backend.ts (modified, +6/-0)
• src/agents/cli-runner.helpers.test.ts (modified, +68/-0)
• src/agents/cli-runner/helpers.ts (modified, +20/-1)
• src/config/types.agent-defaults.ts (modified, +10/-0)

PR #71626: test(cli-runner): bound argv length for large Claude system prompts (#71600)

• Repository: openclaw/openclaw
• Author: stainlu
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/71626

Description (problem / solution / changelog)

Why

f7b71abf48 ("fix(agents): pass Claude system prompt via file") routes the Claude CLI system prompt through --append-system-prompt-file <path> whenever the backend exposes systemPromptFileArg. That fix unblocks the Windows-specific spawn ENAMETOOLONG reported in #71600, where workspace-scale system prompts (~41k chars) blow past Windows' CreateProcessW MAX_COMMAND_LINE limit (~32,767 chars).

Existing coverage in cli-runner.spawn.test.ts ("passes Claude system prompts through a file instead of argv") asserts the file path appears in argv and the prompt body doesn't, but uses a small hardcoded prompt. It doesn't pin the actual regression target — the argv length staying under Windows' OS limit when the prompt is workspace-scale.

What this adds

A focused regression test in src/agents/cli-runner.system-prompt-argv-bound.test.ts:

1. Length bound: with a 40k-char system prompt, the joined argv reaching the supervisor stays under 32,767 chars.
2. Defense-in-depth: the prompt body itself (BEGIN-PROMPT-MARKER/END-PROMPT-MARKER sentinels) never appears anywhere in argv.

This way, a future change that bypasses the file path — even one where argv length stays bounded by accident (truncation, placeholder substitution) — will still fail (2).

Verified

Locally flipped the test backend config from systemPromptFileArg: "--append-system-prompt-file" to systemPromptArg: "--append-system-prompt" (simulating the pre-fix state). Both cases fail under the broken config: the runtime falls back to inlining the prompt and argv blows past the 32k threshold. Restoring the file arg returns both cases to green.

Pure test addition; no production code change. No changelog entry.

Verification

• pnpm test src/agents/cli-runner.system-prompt-argv-bound.test.ts → 2/2 pass
• pnpm format + pnpm lint → clean on the touched file
• Doesn't affect #71600 itself; the fix is already on main from f7b71abf48 and will land in the next release. This locks the bound so it can't quietly regress again.

Changed files

• src/agents/cli-runner.system-prompt-argv-bound.test.ts (added, +168/-0)