[Bug]: generated POSIX service files normalize CODEX_SQLITE_HOME but not CODEX_HOME on a Windows host #1786

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:

1. 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.
2. 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.

1. git clone the repository and check out v2.20.0.
2. bun install --frozen-lockfile
3. bun 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

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.