Client or integration
Other
Area
Platform (Windows / macOS / Linux)
Summary
Six tests fail on the Windows CI shards for reasons that predate the current release range. They are recorded here so the leg's remaining red is a known quantity rather than something the next person re-derives from scratch.
Verified as not caused by main...dev: git log origin/main..origin/dev returns zero commits for every file involved.
Group 1 — WP13 composed acceptance (3 cases), tests/codex-composed-acceptance.test.ts
A-reduced, E: separate fake homes share the effective-user Codex lock, and Restore truth. Each case starts a real ocx start more than once — spawn a Bun runtime, load the CLI, read config, bind a port, publish runtime-port.json — and the Windows runner cannot finish that inside the budget while running a quarter of the suite.
Worth stating plainly: these have never passed on Windows. The 2026-08-18 run I first compared against (32147924436) had shard 4/4 cancelled, so they never executed there at all. "No failures listed" was not "passed".
A cascade on top of this was fixed in #2143: teardown aborted on the first child that would not exit, so survivors were killed by Bun's between-file sweep and the next case failed with exit 143. That is gone; what remains is the underlying cost.
Group 2 — npm cache preflight (3 cases), tests/update-npm-cache-preflight.test.ts
lstats normal nested symlinks but never traverses their targets, a foreign-owned nested symlink does not block the update, and a cache root symlinked to another volume is inspected, not rejected all return cache_entry_inaccessible. An unprivileged Windows user cannot create symlinks, so the fixtures cannot build the shape they assert on. Several neighbouring cases already skip for the same reason.
Group 3 — shard 2 Bun runtime panic
panic(thread): Internal assertion failure — a Bun crash, not a test result. The workflow already carries a crash-signature retry for the macOS leg (is_bun_runtime_crash); the Windows shards have no equivalent.
Reproduction
- Dispatch
ci.yml against dev (the Windows leg only runs on workflow_dispatch).
- Read the
windows 2/4 and windows 4/4 job logs.
- Observe the three groups above. Shard 3/4 passes.
Version
dev @ 525274485
Operating system
windows-latest (GitHub-hosted runner)
Provider and model
Not provider-specific — CI only.
Logs or error output
# WP13
(fail) WP13 composed toggle acceptance > A-reduced: real CLI and HTTP entry points preserve an OFF Codex config/home [79978.97ms]
# npm cache preflight
+ "reason": "cache_entry_inaccessible",
# shard 2
panic(thread 3960): Internal assertion failure
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
Screenshots and supporting files
Analysis and the full before/after table: devlog/_plan/260819_unclaimed_bug_selection/180_windows_leg.md.
For contrast, what #2143 did fix on this leg, all of it caused by the current release range or by the workflow: Log Guard unsafe_path 22 → 0, Bun's 5s default 3 → 0, identity-lookup timeout 4 → 0, WP13 cascade 6 → 3, and shard 3/4 failure → success.
Redacted configuration
{ "note": "CI-only; no user configuration involved" }Checks
Client or integration
Other
Area
Platform (Windows / macOS / Linux)
Summary
Six tests fail on the Windows CI shards for reasons that predate the current release range. They are recorded here so the leg's remaining red is a known quantity rather than something the next person re-derives from scratch.
Verified as not caused by
main...dev:git log origin/main..origin/devreturns zero commits for every file involved.Group 1 — WP13 composed acceptance (3 cases),
tests/codex-composed-acceptance.test.tsA-reduced,E: separate fake homes share the effective-user Codex lock, andRestore truth. Each case starts a realocx startmore than once — spawn a Bun runtime, load the CLI, read config, bind a port, publishruntime-port.json— and the Windows runner cannot finish that inside the budget while running a quarter of the suite.Worth stating plainly: these have never passed on Windows. The 2026-08-18 run I first compared against (32147924436) had shard 4/4 cancelled, so they never executed there at all. "No failures listed" was not "passed".
A cascade on top of this was fixed in #2143: teardown aborted on the first child that would not exit, so survivors were killed by Bun's between-file sweep and the next case failed with exit 143. That is gone; what remains is the underlying cost.
Group 2 — npm cache preflight (3 cases),
tests/update-npm-cache-preflight.test.tslstats normal nested symlinks but never traverses their targets,a foreign-owned nested symlink does not block the update, anda cache root symlinked to another volume is inspected, not rejectedall returncache_entry_inaccessible. An unprivileged Windows user cannot create symlinks, so the fixtures cannot build the shape they assert on. Several neighbouring cases alreadyskipfor the same reason.Group 3 — shard 2 Bun runtime panic
panic(thread): Internal assertion failure— a Bun crash, not a test result. The workflow already carries a crash-signature retry for the macOS leg (is_bun_runtime_crash); the Windows shards have no equivalent.Reproduction
ci.ymlagainstdev(the Windows leg only runs onworkflow_dispatch).windows 2/4andwindows 4/4job logs.Version
dev @
525274485Operating system
windows-latest (GitHub-hosted runner)
Provider and model
Not provider-specific — CI only.
Logs or error output
Screenshots and supporting files
Analysis and the full before/after table:
devlog/_plan/260819_unclaimed_bug_selection/180_windows_leg.md.For contrast, what #2143 did fix on this leg, all of it caused by the current release range or by the workflow: Log Guard
unsafe_path22 → 0, Bun's 5s default 3 → 0, identity-lookup timeout 4 → 0, WP13 cascade 6 → 3, and shard 3/4 failure → success.Redacted configuration
{ "note": "CI-only; no user configuration involved" }Checks