fix(windows): build CSO with /wd5105 and surface probe diagnostics

[AlinValentin7]

PR: fix two Windows build/diagnostic bugs in the CSO toolchain

Branch: fix/windows-cso-build-and-diagnostics (from f30b7b7 / v1.91.13.0)
Scope: 2 files, 16 insertions, 4 deletions. No behaviour change on macOS/Linux paths.

---

Summary

1. scripts/build-cso-windows.ps1 — the CSO Windows build fails inside a system
   header because warning C5105 from the Windows SDK's own winbase.h is
   promoted to error C2220 by /W4 /WX. Added /wd5105 to both cl calls.
2. setup — the CSO toolchain probe discards all output
   (>/dev/null 2>&1) and maps every failure to windows-msvc-toolchain, whose
   message tells the user to "install Visual Studio 2022 Build Tools with
   Desktop development with C++". That advice is wrong whenever the toolchain is
   already present and the failure came from a compile step. The probe's own
   diagnostics are now forwarded to stderr.

Side effect worth noting: the same compile failure also broke
test/cso-windows-launcher.test.ts, whose fixture compiles launcher-windows.c.
Fixing the build takes that suite from 46 to 64 passing tests (details below).

---

1. build-cso-windows.ps1: /wd5105

Repro

Windows 11 · VS 2022 Build Tools with Microsoft.VisualStudio.Component.VC.Tools.x86.x64 ·
Windows SDK 10.0.19041.0 only · Git Bash · ./setup --host codex --prefix

launcher-windows.c
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9572):
    error C2220: the following warning is treated as an error
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9572):
    warning C5105: macro expansion producing 'defined' has undefined behavior
Native CSO Windows helper compilation failed (2).

The diagnostic is raised in a header the project does not own, for a construct the
project cannot change, and /WX turns it fatal. A trivial
int main(void){return 0;} compiles cleanly with the same flags, which is why the
-CheckOnly probe passes while the real sources do not.

Fix

/wd5105 on both cl invocations (probe and build). /WX is kept for every
warning the project can act on; only this one SDK-internal diagnostic is
disabled. Chosen over removing /WX (which would weaken real checks) and over
requiring a newer Windows SDK (which raises the install bar).

Verification

vswhere already resolved
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools with
VC.Tools.x86.x64, so this was never a missing-toolchain problem. Before and
after on the same machine, same SDK, same MSVC:

	Before	After
CSO build	Native CSO Windows helper compilation failed (2)	succeeds
bin/gstack-cso-launcher.exe	—	134 KB
bin/gstack-cso-core.exe	—	produced
bin/.gstack-cso-generation (+ .lock)	—	produced
./setup tail	CSO unavailable: its native helper was not built	gstack ready (codex).

No source was modified other than the two cl flag lists.

---

2. setup: stop hiding the CSO probe's diagnostics

# before
if ! powershell.exe ... -CheckOnly >/dev/null 2>&1; then
  _cso_unavailable "windows-msvc-toolchain"
fi

# after
if ! _cso_probe_out="$(powershell.exe ... -CheckOnly 2>&1)"; then
  _cso_unavailable "windows-msvc-toolchain"
  [ -n "$_cso_probe_out" ] && printf '%s\n' "$_cso_probe_out" >&2
fi

Why this matters

windows-msvc-toolchain is produced by any probe failure, and its
prerequisite text (setup line 3340) always says "install Visual Studio 2022
Build Tools with Desktop development with C++". On this machine that advice was
a dead end: the toolchain was present and the identical -CheckOnly probe exits
0 under both powershell.exe 5.1 and pwsh 7 when its output is visible.
With the output discarded there is no way to tell "toolchain missing" from
"compile step failed", so the user follows the wrong instruction.

Forwarding stderr costs one line and makes the reason code actionable.

---

3. Test results (before vs after, same machine)

Targeted at the two changed files. Commands run fresh for this PR.

bun test test/cso-windows-launcher.test.ts test/setup-help.test.ts test/setup-needs-build.test.ts

	f30b7b7 (before)	this branch (after)
pass	46	64
skip	2	2
fail	1	1

The before-state failure is:

error: Fixture launcher compilation failed: launcher-windows.c
Native CSO Windows helper compilation failed (2).
(fail) (unnamed)

The fixture compiles launcher-windows.c through the same
build-cso-windows.ps1, so it hit the identical C5105 abort and 18 tests never
executed. With /wd5105 the fixture builds and all 67 run.

The remaining failure is not introduced by this change, but it is newly
visible because the suite can now reach it. It lives in CSO native Windows startup and varies between 1 and 2 names across runs (flaky):

(fail) CSO native Windows startup > BUN_OPTIONS cannot execute a preload before the environment is scrubbed
(fail) CSO native Windows startup > NTFS high file IDs survive repeated native commands and ambiguous old decisions remain blocked

Both assert runtime behaviour of launcher-windows.c and lib/cso/witness.ts,
which this diff does not touch. Reported rather than silently left out of the PR.

Separately, test/cso-witness.test.ts fails identically before and after
(6 pass / 5 fail at both f30b7b7 and this branch), all with
CsoError: UNSAFE_PATH "Assertion witness working directory must be private and owned" from lib/cso/witness.ts:657 — a POSIX uid/mode check that cannot hold
on NTFS. Pre-existing and Windows-specific, unrelated to this diff.

---

4. Related, not included here: --prefix does not make name spec-conformant

Raising it as a design question rather than patching it, since it touches
hosts/* and scripts/external-skill-names.ts.

The Agent Skills spec requires name to
match the parent directory name. After ./setup --host codex --prefix, the
directories are gstack-qa/, gstack-autoplan/ … but the emitted frontmatter
still carries the upstream short name:

~/.codex/skills/gstack-qa/SKILL.md
---
name: qa            <-- directory is gstack-qa

Across a mixed install this is 98 non-conformant skills out of 467. In source the
two agree (qa/ with name: qa), so the mismatch is introduced only by the
install-time prefixing.

bin/gstack-relink already performs exactly the needed rewrite and documents it
as "name: line rewritten to NAME, which is how alias and prefixed copies differ" —
but it targets SKILLS_DIR=$(dirname INSTALL_DIR), not the host's own skill root,
and a failing ./setup tail aborts before it runs. Re-running ./setup then
resets the patch: the source tree goes back to name: qa and the generated
copies follow.

So a --prefix install needs an out-of-tree repair step after every upgrade. The
clean fix is for generation to emit the prefixed name whenever SKILL_PREFIX is
on — externalSkillName() already computes it (gstack-${base}, with an
idempotence guard for names already prefixed), so it looks like a question of
where the frontmatter name is taken from in gen-skill-docs.ts versus
hosts/<host>.ts frontmatter.keepFields.

Happy to implement it if the maintainers agree that --prefix should imply
spec-conformant name values on every host.

---

Checklist

• No behaviour change on macOS/Linux paths
• /WX retained for project-relevant warnings
• Verified on Windows 11 + VS 2022 Build Tools + Windows SDK 10.0.19041.0
• ./setup --host codex --prefix --no-team completes; /cso artifacts produced
• bun test run before and after on the 3 files covering the change: 46 → 64 pass, failure count unchanged at 1
• test/cso-witness.test.ts confirmed failing identically at the base commit
• Full bun test not run (the two remaining failures are pre-existing / flaky on Windows and are itemised above)

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[capy-ai]

Thank you, @AlinValentin7. Your fix is folded into v1.91.19.0 (#3025), which is now merged, and you're credited as a co-author on the release commit and in the CHANGELOG. Closing this PR because the change is on main now.