Greptile Summary

This PR adds Windows custom shell support to src/agents/shell-utils.ts, letting users specify their preferred shell via OPENCLAW_SHELL or SHELL on Windows (previously hardcoded to PowerShell). The new resolveConfiguredWindowsShell helper correctly handles arg-style selection (/c for cmd, -NoProfile -NonInteractive -Command for PowerShell variants, -c for unix-like shells), strips paired quotes from env-var paths, and rejects invalid POSIX-style paths on Windows with a clean fallback. Both getShellConfig() and detectRuntimeShell() are updated to use the same resolution logic, fixing a pre-existing inconsistency between the two functions on Windows.

Confidence Score: 5/5

Safe to merge; all remaining findings are P2 style suggestions that do not affect correctness in realistic configurations.

The implementation is well-structured with correct arg-style selection, proper POSIX path rejection, quote-stripping, and ordered OPENCLAW_SHELL → SHELL fallback. Tests cover all new branches. The one flagged issue (isUnixLikeShellName substring match) only matters if a user deliberately sets SHELL to a non-shell binary on Windows, which is very unlikely in practice.

No files require special attention; the shell resolution logic in shell-utils.ts is straightforward to follow and well-tested.

This is a comment left during a code review.
Path: src/agents/shell-utils.ts
Line: 129-138

Comment:
**`name.includes("sh")` matches non-shell programs**

The substring check `name.includes("sh")` is overly broad: values like `"ssh"`, `"tsh"`, or `"tmsh"` will satisfy `isUnixLikeShellName`, causing them to be accepted as a unix-like shell on Windows. A user with `SHELL=ssh` (not implausible in developer tooling environments) would end up with `{ shell: "ssh", args: ["-c"] }` instead of falling through to the PowerShell default.

Consider using a closed allowlist of recognised short names instead:

```suggestion
function isUnixLikeShellName(name: string): boolean {
  return (
    name === "nu" ||
    name === "nushell" ||
    name === "fish" ||
    name === "bash" ||
    name === "zsh" ||
    name === "ksh" ||
    name === "sh" ||
    name === "ash" ||
    name === "dash" ||
    name === "csh" ||
    name === "tcsh" ||
    name === "mksh" ||
    name === "pdksh"
  );
}
```
Or keep the prefix/contains approach but explicitly exclude known non-shell programs that contain "sh".

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into codex/windows-s..." | Re-trigger Greptile}

Codex automated review: keeping this open.

Keep this PR open. Current main still hardcodes Windows host exec to PowerShell and does not expose a custom Windows shell selection surface in code, config, or docs. The PR is a live implementation candidate, but its proposed OPENCLAW_SHELL override conflicts with documented runtime-marker semantics and still has review concerns around validating configured shell names and paths. Related open PR #39413 tracks a broader config-backed solution, but it is not merged and should be consolidated through maintainer review rather than used as an auto-close reason.

Best possible solution:

Keep this PR open for maintainer review and consolidate direction with #39413. The best implementation should choose a stable public surface, likely config-backed tools.exec.shell / per-agent override or a deliberately named environment override, validate Windows explicit paths and bare names against PATH/PATHEXT, preserve PowerShell defaults, and update config schema, docs, and regression tests together.

What I checked:

• Current Windows exec shell selection is still hardcoded: getShellConfig() returns resolvePowerShellPath() with -NoProfile -NonInteractive -Command whenever process.platform === "win32"; that branch does not consult SHELL, OPENCLAW_SHELL, or config. (src/agents/shell-utils.ts:54, 4878d3e059ce)
• Host exec uses getShellConfig on the command execution path: The exec runtime builds childArgv from getShellConfig() before spawning host commands, so the hardcoded Windows selection affects actual user-facing exec behavior. (src/agents/bash-tools.exec-runtime.ts:708, 4878d3e059ce)
• Docs still document PowerShell fallback, not custom Windows shells: The exec docs say non-Windows hosts use SHELL, while Windows hosts prefer PowerShell 7 discovery and then Windows PowerShell 5.1. The same section documents OPENCLAW_SHELL=exec as a spawned-command context marker. Public docs: docs/tools/exec.md. (docs/tools/exec.md:73, 4878d3e059ce)
• OPENCLAW_SHELL is already reserved in public environment docs: Environment docs define OPENCLAW_SHELL values such as exec, acp, acp-client, and tui-local as runtime-injected markers, making reuse as a user shell override a product/API decision. Public docs: docs/help/environment.md. (docs/help/environment.md:59, 4878d3e059ce)
• Current config schema has no exec shell override: ExecToolConfig and the runtime zod shape include host, security, ask, node, PATH, safe-bin, timeout, cleanup, notification, and apply-patch fields, but no shell field. (src/config/types.tools.ts:242, 4878d3e059ce)
• Live PR context shows this remains an open implementation candidate: GitHub API shows this PR is open and unmerged, touching only src/agents/shell-utils.ts and src/agents/shell-utils.test.ts. Review comments flag unresolved validation concerns for missing configured shell paths and unresolved bare shell names.

Remaining risk / open question:

• Closing now could discard a plausible Windows exec usability fix that is not implemented on current main.
• The proposed OPENCLAW_SHELL override conflicts with current runtime-marker docs and needs maintainer API/product direction.
• The PR still needs validation review for stale explicit paths and bare shell names before it would be safe to merge.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 4878d3e059ce.