Client or integration
Other
Area
Platform (Windows / macOS / Linux)
Summary
tests/service.test.ts fails on a Windows host in two cases — systemd service unit > preserves custom Codex and OpenCodex homes and launchd service plist > preserves custom Codex and OpenCodex homes. Both assert that a POSIX service file round-trips a custom CODEX_SQLITE_HOME, but the value comes back normalized: the test sets /tmp/... and the generated unit carries C:\tmp\....
The reason this looks like a real defect rather than "POSIX tests on the wrong host" is the asymmetry inside the same test: CODEX_HOME survives unnormalized in the very same generated file, while CODEX_SQLITE_HOME does not. Two environment variables holding the same kind of value are treated differently by the same code path. Whatever normalizes one should normalize both, or neither.
Two readings are possible and I cannot distinguish them from outside:
- The generator normalizes
CODEX_SQLITE_HOME and should not — a POSIX unit file must carry the literal POSIX path regardless of the host that writes it. If a Windows host can legitimately emit a systemd unit (for a WSL or remote target), this would be a real product bug, not a test bug.
- Only the test is host-dependent, and the fix is to pin the platform or skip on Windows.
Either way the current state costs something: the two failures are permanent noise on Windows, and a permanent expected failure is exactly the kind of thing that later swallows a genuine regression in the same case.
This is almost certainly invisible in CI, which I assume is POSIX — there the paths never get normalized and both cases pass.
I have carried these two as tolerated-by-name failures locally for several releases. I am reporting rather than continuing to tolerate them, because the asymmetry above suggests the first reading is at least possible.
Reproduction
Verified on a clean v2.20.0 checkout with no local patches applied.
git clone the repository and check out v2.20.0.bun install --frozen-lockfilebun test tests/service.test.ts
Observed on Windows: 119 pass / 2 fail, the two failures being
(fail) systemd service unit > preserves custom Codex and OpenCodex homes
(fail) launchd service plist > preserves custom Codex and OpenCodex homes
The test sets CODEX_SQLITE_HOME="/tmp/..." and expects the literal back; the generated unit contains C:\tmp\.... In the same generated file, CODEX_HOME retains its unnormalized POSIX value.
Expected: either the generated POSIX service file preserves both variables literally, or both cases are pinned/skipped on non-POSIX hosts so the suite result is meaningful.
For comparison, the same file was 111 pass / 2 fail on v2.14.1 — the two failures are long-standing and stable across releases, not a recent regression.
Version
2.20.0
Operating system
Windows 11 Home Single Language 26200
Provider and model
Not applicable — no provider involved.
Logs or error output
$ bun test tests/service.test.ts
bun test v1.3.14
(fail) systemd service unit > preserves custom Codex and OpenCodex homes [2.62ms]
(fail) launchd service plist > preserves custom Codex and OpenCodex homes [1.43ms]
119 pass
2 fail
Redacted configuration
Checks
Client or integration
Other
Area
Platform (Windows / macOS / Linux)
Summary
tests/service.test.tsfails on a Windows host in two cases —systemd service unit > preserves custom Codex and OpenCodex homesandlaunchd service plist > preserves custom Codex and OpenCodex homes. Both assert that a POSIX service file round-trips a customCODEX_SQLITE_HOME, but the value comes back normalized: the test sets/tmp/...and the generated unit carriesC:\tmp\....The reason this looks like a real defect rather than "POSIX tests on the wrong host" is the asymmetry inside the same test:
CODEX_HOMEsurvives unnormalized in the very same generated file, whileCODEX_SQLITE_HOMEdoes not. Two environment variables holding the same kind of value are treated differently by the same code path. Whatever normalizes one should normalize both, or neither.Two readings are possible and I cannot distinguish them from outside:
CODEX_SQLITE_HOMEand should not — a POSIX unit file must carry the literal POSIX path regardless of the host that writes it. If a Windows host can legitimately emit a systemd unit (for a WSL or remote target), this would be a real product bug, not a test bug.Either way the current state costs something: the two failures are permanent noise on Windows, and a permanent expected failure is exactly the kind of thing that later swallows a genuine regression in the same case.
This is almost certainly invisible in CI, which I assume is POSIX — there the paths never get normalized and both cases pass.
I have carried these two as tolerated-by-name failures locally for several releases. I am reporting rather than continuing to tolerate them, because the asymmetry above suggests the first reading is at least possible.
Reproduction
Verified on a clean v2.20.0 checkout with no local patches applied.
git clonethe repository and check outv2.20.0.bun install --frozen-lockfilebun test tests/service.test.tsObserved on Windows:
119 pass / 2 fail, the two failures beingThe test sets
CODEX_SQLITE_HOME="/tmp/..."and expects the literal back; the generated unit containsC:\tmp\.... In the same generated file,CODEX_HOMEretains its unnormalized POSIX value.Expected: either the generated POSIX service file preserves both variables literally, or both cases are pinned/skipped on non-POSIX hosts so the suite result is meaningful.
For comparison, the same file was
111 pass / 2 failon v2.14.1 — the two failures are long-standing and stable across releases, not a recent regression.Version
2.20.0
Operating system
Windows 11 Home Single Language 26200
Provider and model
Not applicable — no provider involved.
Logs or error output
Redacted configuration
{}Checks