PR #68817: fix: add claude, codex, hermes to Windows .cmd shim allowlist

• Repository: openclaw/openclaw
• Author: kagura-agent
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/68817

Description (problem / solution / changelog)

Fixes #68788

On Windows, spawning claude (and similar CLI tools installed via npm) fails with ENOENT because resolveWindowsCommandShim only appends .cmd for a hardcoded allowlist of commands (npm, pnpm, yarn, npx).

This PR adds claude, codex, and hermes to the cmdCommands array so their .cmd shims are found on Windows.

Also adds a test covering the new entries.

Changed files

• src/process/supervisor/adapters/child.ts (modified, +1/-1)
• src/process/windows-command.test.ts (modified, +12/-0)

---

PR #68819: fix: resolve Windows .cmd shims to underlying .exe before spawn

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

Description (problem / solution / changelog)

Summary

• Problem: On Windows, every provider=claude-cli spawn fails at the supervisor with spawn claude ENOENT; the fallback chain cascades and the user sees Embedded agent failed before reply.
• Why it matters: Claude CLI is unusable on Windows — Discord, webchat, and any other channel routing to claude-cli is broken.
• What changed: .cmd shims are now resolved to their underlying .exe (or node.exe <cli.js>) and spawned directly, bypassing Node's CVE-2024-27980 restriction on .cmd and cmd.exe's argument-escaping limits. "claude" added to the supervisor's cmdCommands allowlist.
• What did NOT change (scope boundary): no non-Windows behavior changed, resolveChildProcessInvocation in exec.ts is untouched, and shims with non-npm-bin bodies fall through to the original spawn path.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #68788
• Related N/A
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: "claude" was missing from the supervisor's cmdCommands allowlist, so resolveWindowsCommandShim returned "claude" unchanged and spawn("claude", …) failed ENOENT. Adding "claude" then surfaces a second bug: Node >=18.20.2 rejects spawn("claude.cmd", …) with EINVAL (CVE-2024-27980), and wrapping via cmd.exe /d /s /c fails because system prompts contain \r \n & | < > ^ % which cmd.exe cannot parse.
• Missing detection / guardrail: no coverage for spawning non-npm .cmd shims through the supervisor's child adapter on Windows.
• Contributing context (if known): resolveNpmArgvForWindows in src/process/exec.ts already solves the .cmd-vs-CVE problem for npm/npx, but the supervisor's createChildAdapter does not route through resolveChildProcessInvocation, so it did not inherit that protection.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/process/windows-command.test.ts
• Scenario the test should lock in: resolveWindowsCmdShimArgv rewrites argv[0] from a .cmd shim to its underlying .exe, prepends process.execPath for .js targets, performs PATH lookup for bare names, and leaves argv unchanged on non-Windows / missing file / non-matching shim body.
• Why this is the smallest reliable guardrail: the bug lives entirely in how the supervisor resolves the command before spawn, so unit-testing the resolver covers it without a full Windows spawn harness.
• Existing test that already covers this (if any): none
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• claude-cli-backed providers now spawn successfully on Windows where they previously failed with spawn claude ENOENT.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (Yes but narrowly)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: The helper reads argv[0] as a path and spawns the .exe it names. The path source is unchanged — it comes from OpenClaw's own resolveCommand output and process.env.PATH, same as before. The regex matches only the narrow npm-bin shim pattern ("%dp0%…target.(exe|js)" %*); any non-matching shim falls through and the original argv is spawned as-is. No new untrusted input is introduced.

Repro + Verification

Environment

• OS: Windows 11 Pro 10.0.26200 (x64)
• Runtime/container: Node.js v22.22.2
• Model/provider: claude-cli (Anthropic @anthropic-ai/claude-code, claude.cmd on PATH)
• Integration/channel (if any): Discord (also reproduces on webchat)
• Relevant config (redacted): default, Claude CLI authenticated via claude login

Steps

1. npm i -g openclaw on Windows.
2. npm i -g @anthropic-ai/claude-code.
3. openclaw gateway start, send a message via Discord.

Expected

• Message routes to claude-cli, the CLI spawns, bot replies.

Actual

[process/supervisor] spawn failed: reason=Error: spawn claude ENOENT [model-fallback/decision] decision=candidate_failed ... detail=spawn claude ENOENT (repeats across opus-4-7, sonnet-4-6, opus-4-6, opus-4-5, sonnet-4-5, haiku-4-5) Embedded agent failed before reply: spawn claude ENOENT

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

After pnpm test src/process/windows-command.test.ts: 10 passed. After live Discord run: claude.exe spawns with an absolute path, bot replies normally, no supervisor errors.

Human Verification (required)

• Verified scenarios: end-to-end Discord message flow on Windows 11 (fails before, succeeds after); pnpm check; pnpm build; bundled dist wires the new helper through correctly.
• Edge cases checked: bare-name .cmd resolved via PATH; .js target resolved to node.exe <cli.js>; missing shim file and non-matching shim body both fall through unchanged.
• What I did not verify: .bat shim bodies (only .cmd tested); non-npm shim formats (chocolatey/scoop) — these fall through unchanged but aren't exercised.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)

Risks and Mitigations

• Risk: a hand-written .cmd whose body coincidentally matches the regex but also does additional batch work (env sets, chained commands) would be bypassed in favor of the detected target.
  • Mitigation: the regex is anchored to the quoted-target + %* shape npm/pnpm/yarn shims use; custom batch scripts with control flow won't match and fall through untouched.

Changed files

• src/process/supervisor/adapters/child.ts (modified, +10/-3)
• src/process/windows-command.test.ts (modified, +212/-1)
• src/process/windows-command.ts (modified, +95/-0)

---

PR #68849: fix: add "claude" to Windows cmdCommands shim allowlist

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

Description (problem / solution / changelog)

Fixes #68788

Summary

resolveWindowsCommandShim resolves .cmd shims for Node spawn() on Windows. The allowlist includes npm, pnpm, yarn, npx but is missing claude, causing spawn claude ENOENT when routing to the claude-cli provider.

Changes

Added "claude" to the cmdCommands array in src/process/supervisor/adapters/child.ts.

Test Plan

• On Windows with claude.cmd on PATH, verify provider=claude-cli model calls succeed
• On non-Windows, no behavior change (resolveWindowsCommandShim is a no-op)

Changed files

• src/process/supervisor/adapters/child.ts (modified, +1/-1)