[lidge-jun]

Layer L1 of the Windows issue sweep stack. Base is L0 (codex/win-sweep-roadmap), not dev — enforce-target will flag this and that is expected for a manual chain. Do not retarget it at dev; that would collapse the chain into overlapping diffs.

Closes the Windows half of #131 for provider-bridge. The GUI and cxc serve copies are L6.

The bug

On Windows an npm global install lays down both an extensionless sh shim and a .cmd launcher, and where ocx lists the extensionless one first. Two independent failures follow, measured on the reporting host:

C:\nvm4w\nodejs\ocx                  status=null  err=ENOENT
C:\nvm4w\nodejs\ocx.cmd              status=null  err=EINVAL
C:\nvm4w\nodejs\ocx.cmd via ComSpec  status=0     stdout=3931 bytes

The extensionless file is not an executable image, and after the CVE-2024-27980 hardening a shell-less .cmd spawn is EINVAL. Both land on status === null, so a healthy proxy was reported as mode: "error" with reason: "ocx status exited null".

The fix, and why not the obvious one

The obvious fix is to pick a better line out of where stdout and wrap the .cmd in a ComSpec call. That was the first implementation, and an independent review rejected it: it would have been a third bespoke ComSpec wrapper in a repository that already has win-exec.ts in four components, and its naive "${path}" quoting is a command injection. Reviewer reproduction: with a launcher path containing &, plain quoting makes cmd execute only the prefix and return status 1, while commandInvocation escapes it to ^& and returns status 0.

So this layer copies cxc-ops/src/win-exec.ts into provider-bridge byte-for-byte and routes through it:

• whichOcx calls resolveWindowsCommand, which reads PATH/PATHEXT case-insensitively (a child can arrive with Path, PATH, or both), splits PATH on a literal ; rather than node:path's host-dependent delimiter, and retries the lowercased extension for case-sensitive filesystems. The where-stdout parsing is deleted, not patched.
• runOcxStatus calls commandInvocation, which routes only .cmd/.bat through ComSpec and escapes cmd metacharacters. shell: true is not used — Node does not escape there.

cli.ts is 66 lines deleted for 31 added. detect.ts is untouched; the detect-only contract holds — no ocx ensure, no ocx sync, no config write.

Why a copy rather than the re-export messenger-bridge uses

A cross-component import is not illegal here — build.mjs's convention is a comment, not a check, and messenger-bridge/src/win-exec.ts already re-exports subagent-config/dist/win-exec.js. But provider-bridge runs from a SessionStart hook that must always exit 0, so depending on another component's dist/ build state would turn a resolution failure into a silent provider-status degradation. The copy removes that coupling; the drift cost is converted into a loud test failure by a byte-identity assertion.

Verification

provider-bridge suite: 13 passed, 0 failed
npm run build: 180 files compiled, layout validated
npm run gate: OK

Live, from the built dist/ on the reporting host:

$ node plugins/codexclaw/components/provider-bridge/dist/cli.js detect
{"provider":"ocx","mode":"provider","ocxPath":"C:\\nvm4w\\nodejs\\ocx.CMD","running":true,"defaultProvider":"openai","port":10100}

The parent commit emits {"mode":"error","reason":"ocx status exited null"} for the same command.

The test that actually gates this

The three helper tests exercise win-exec.ts directly and all pass when cli.ts is untouched — copying the module alone would satisfy them. An audit caught that hole, so there are now two win32 subprocess tests that run the real cli.ts detect against a crafted PATH holding both an extensionless shim and a .cmd that answers status --json. They assert mode === "provider", that the resolved path is the launcher, and that running/port came back, so they fail if either half regresses or if the wiring is missing.

Known coverage limit: those two are win32-only, because the fixture needs a real .cmd. Linux and macOS CI do not gate the wiring — only the Windows matrix jobs do.

One behaviour difference, recorded rather than hidden

resolveWindowsCommand builds candidates with PATHEXT's own spelling and Windows existsSync ignores case, so the reported path ends .CMD where the old where-parsing reported the on-disk .cmd. Caught by the new tests on first run. Cosmetic — Windows paths are case-insensitive and the only consumer reads ocxPath as a path. It must not be normalised inside win-exec.ts, whose bytes are shared with four components; the tests compare case-insensitively and assert /\.cmd$/i, pinning that the shim lost rather than a spelling.

dist/win-exec.js is a new file and .gitignore:2 ignores dist/, so it required git add -f.

Plan: devlog/_plan/260911_windows_issue_sweep/010_wp2_provider_bridge_windows_detect.md.

[github-actions]

✅ Target branch corrected

This pull request now targets dev.

The [WRONG BRANCH] title prefix has been removed. Its existing draft status has been preserved.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-11T11:44:41.689961Z	745ab99	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[lidge-jun]

Superseded by the rebased PR against \dev. GitHub auto-closed this one when the L0 base branch was deleted by that merge, and reopening was refused because the head had already been rebased. Content is unchanged.