Repository navigation
bug: WSL receiver cannot read active native Windows Codex SQLite state #156
Description
RC1 validation blocker from #150
The documented WSL2 receiver for a native Windows Codex session cannot discover the active native thread on this host. Managed enrollment, public WSS attachment and pinned pairing succeed, but list returns discovery_failed and no targets.
The receiver uses the documented fixed codexHome=/mnt/c/Users/<USER>/.codex and native mounted codexBin=.../codex.exe. Reproducing locally inside WSL with the installed RC1 CLI identifies the cause:
session-peer list --agent codex --codex-home /mnt/c/Users/<USER>/.codex --json
state_db_read_failed: Cannot read Codex state DB .../state_5.sqlite: disk I/O error
Native Windows RC1 list against the same home succeeds and discovers the live user-activated test session. Environment: WSL2 Ubuntu 24.04, Python 3.12.3, session-peer[relay] 1.0.0rc1, websockets 17.1, cryptography 50.0.1; native Windows Python 3.10.0. No database contents/credentials attached, and no DB mutation or live DB copy was attempted.
Investigate Linux SQLite access to the active Windows database across the mounted filesystem and ensure the advertised WSL-to-native adapter has a supported discovery path (for example a bounded native-side query, if appropriate after design review). Do not disable locking, use immutable=1 against a changing live DB, or report empty discovery as success.
Acceptance: live native Windows writer stays active; WSL receiver lists the configured native target, dry-run resolves it, and one authorized relay send produces an actual ACK. Keep fixed executable/home policy restrictions and regression tests. This is independent of #153's Windows-local writer-lock probe. The WSL native-target gate remains failed until fixed and revalidated in RC2.
Activity
abruption commentedon Sep 22, 2026
Additional RC1 evidence: one authorized public-relay send to the fixed native Codex alias returned
native_outcome_unknown. A subsequent read-only status query preserved the same durable unknown outcome. The message was not retried and no actual ACK was observed. Pairing/enrollment success is therefore not evidence of native delivery; preserve this unknown request journal during the RC2 investigation.abruption commentedon Sep 22, 2026
Candidate validation now passes through the public Relay → WSL receiver → native Windows Codex path. Fixed operator-owned native Python reads Windows SQLite/WAL and performs strict native writer checks; no Linux SQLite access or inactive-writer bypass. Live list and dry-run succeeded, one fresh request 3599c4c1-a6c4-43e0-b228-a29d13e47d21 queued, and the user independently confirmed exact ACK WIN-RELAY-156-a29d13e4. Existing unknown request was not replayed and the receiver identity/journal were preserved. Default installed RC1 was not replaced; validation used isolated candidate source. PR and CI are in preparation; issue remains open.
abruption commentedon Sep 24, 2026
RC4 five-host rerun rc4-rerun-02 completed 14,436.65 s. The WSL receiver to native Windows Codex path was exercised at T0/T120/T240 with exact TUI ACKs; relay probes were 147/147 overall and Windows relay probes 49/49. The configured native home/executable policy remained fixed. Closing the RC1 mounted-SQLite regression; this is not a claim about arbitrary Windows SSH shells (#151).