On Windows, falling back to plain "bash" when resolveWindowsBash() returns null can still hit the System32 WSL stub (the original failure mode), so this wrapper may not actually fix the Windows build in that case. Consider either (a) treating a null resolution as a hard error with a clear message, or (b) searching PATH for bash.exe while explicitly excluding %SystemRoot%\System32\bash.exe / WSL stubs.

resolveWindowsBash() only checks existsSync(candidate). If OPENCLAW_GIT_BASH/GIT_BASH_PATH is set to a directory (or non-executable), existsSync will return true and spawnSync will then fail in a less obvious way. Prefer validating with statSync(candidate).isFile() (and optionally checking .exe suffix on win32) before returning it.

Throwing result.error here will surface a Node stack trace in npm/pnpm output, which is noisy for a script entrypoint and inconsistent with other repo scripts that print a concise error then exit non-zero (e.g., scripts/test-force.ts). Consider printing result.error.message (plus the Git Bash hint) and calling process.exit(1) instead of throwing.

Missing newline at end of file

The file is missing a trailing newline, as noted by the \ No newline at end of file marker in the diff. Most linters and POSIX tools expect files to end with a newline.

This is a comment left during a code review.
Path: scripts/bundle-a2ui.mjs
Line: 51

Comment:
**Missing newline at end of file**

The file is missing a trailing newline, as noted by the `\ No newline at end of file` marker in the diff. Most linters and POSIX tools expect files to end with a newline.

```suggestion
process.exit(result.status ?? 1);
```

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

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Non-Windows error path lacks diagnostic context

When result.error is set (e.g. ENOENT) and the platform is not Windows, the error is re-thrown with no accompanying message. On Linux/macOS this would be a misconfigured environment where bash is genuinely absent, which is unusual but possible in minimal CI containers. Adding a cross-platform fallback message makes the failure easier to diagnose without changing the throw semantics.

This is a comment left during a code review.
Path: scripts/bundle-a2ui.mjs
Line: 42-48

Comment:
**Non-Windows error path lacks diagnostic context**

When `result.error` is set (e.g. `ENOENT`) and the platform is *not* Windows, the error is re-thrown with no accompanying message. On Linux/macOS this would be a misconfigured environment where `bash` is genuinely absent, which is unusual but possible in minimal CI containers. Adding a cross-platform fallback message makes the failure easier to diagnose without changing the throw semantics.

```suggestion
if (result.error) {
  if (process.platform === "win32") {
    console.error(
      "A2UI bundling requires Git Bash on Windows. Set OPENCLAW_GIT_BASH to bash.exe if Git is installed in a non-standard location.",
    );
  } else {
    console.error(
      `A2UI bundling failed to spawn '${shell}': ${result.error.message}`,
    );
  }
  throw result.error;
}
```

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

scriptPath is built with path.join, which will use backslashes on Windows. Git Bash/MSYS tools are generally happier with forward slashes (and the previous package.json invocation used scripts/bundle-a2ui.sh with /). Consider normalizing scriptPath to use / (e.g., replace \\ with /) before passing it to bash to avoid path-translation edge cases.

The Windows Git Bash lookup misses the common per-user installation location (%LOCALAPPDATA%\\Programs\\Git\\bin\\bash.exe / ...\\usr\\bin\\bash.exe). Without this, many “standard” Git for Windows installs done as “Just for me” won’t be detected and you’ll hit the fallback bash resolution again.

The error text only mentions OPENCLAW_GIT_BASH, but the resolver also accepts GIT_BASH_PATH. To reduce confusion when users try to follow the guidance, consider mentioning both supported env vars (or standardizing on one) in this message.

On Windows, if resolveWindowsBash() returns null you fall back to invoking bash anyway. If that resolves to the System32 WSL stub, the process will typically exit non-zero without setting result.error, so this wrapper won’t emit the helpful Git Bash guidance and the original failure mode remains. Consider failing fast when no Git Bash candidate is found, or (at least) printing the guidance when result.status !== 0 and the wrapper used the fallback bash.