[Bug]: WSL service state records ~/.codex instead of the runtime-detected Windows Codex home

[Ted151951]

Client or integration

Codex App

Area

Service lifecycle; Platform (Windows / Linux / WSL)

Summary

In the Windows Codex Desktop + WSL app-server layout supported by #63, OpenCodex uses two different Codex-home resolvers.

Runtime/config paths use the WSL-aware resolver and discover the Windows Desktop home. Service install state instead uses CODEX_HOME || homedir()/.codex. A service installed from an ordinary WSL shell therefore records the Linux fallback in service-state.json, even though the proxy runtime resolves the Windows Codex home.

Later service repair or service uninstall commands run from the Desktop-injected environment report a false ownership mismatch or direct restore logic toward the wrong home.

Expected: service ownership metadata should use the same canonical resolver as the proxy runtime, without requiring CODEX_HOME to be baked into the systemd environment.

Reproduction

1. Use Windows Codex Desktop with the agent running in WSL2.

2. Ensure Linux ~/.codex/config.toml is absent and exactly one Windows Codex config is visible at /mnt/c/Users/<windows-user>/.codex/config.toml.

3. Run:

   env -u CODEX_HOME -u OPENCODEX_HOME ocx status

   OpenCodex correctly reports /mnt/c/Users/<windows-user>/.codex.

4. Install the Linux user service from the same ordinary WSL environment:

   env -u CODEX_HOME -u OPENCODEX_HOME ocx service install

5. Inspect ~/.opencodex/service-state.json. Its codexHome is /home/<wsl-user>/.codex.

6. From a Codex Desktop WSL task, where CODEX_HOME=/mnt/c/Users/<windows-user>/.codex, run ocx service repair.

7. Observe the ownership mismatch between the recorded Linux home and the Desktop home.

Code path:

function currentCodexHome(): string {
  const raw = process.env.CODEX_HOME?.trim();
  return raw ? resolve(expandUserPath(raw)) : join(homedir(), ".codex");
}

This bypasses the WSL-aware resolver already used by normal runtime paths.

Version

2.11.1

Operating system

Windows 11 with WSL2 / Ubuntu; Codex Desktop agent mode set to WSL

Logs or error output

Service was installed with CODEX_HOME=/home/<wsl-user>/.codex,
but current CODEX_HOME=/mnt/c/Users/<windows-user>/.codex.

Redacted configuration

{
  "desktopAgentMode": "WSL",
  "linuxConfigPresent": false,
  "windowsCodexHomeCandidates": 1
}

Checks

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

Relationship

Follow-up to #63. Companion split-SQLite issue: #1401.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Ted151951]

Companion issue for the split SQLite state path is #1401. The two bugs share the Windows Desktop + WSL layout but have separate fixes: #1400 is service ownership/home resolution; #1401 is CODEX_SQLITE_HOME/history database resolution.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

Confirmed on current dev. src/service.ts still resolves service ownership with CODEX_HOME || homedir()/.codex, while the runtime uses the WSL-aware resolver in src/codex/home.ts. In the single-Windows-home WSL layout, those can name different homes exactly as reported.

I will patch the service install-state and ownership comparison to use the same canonical resolver as the runtime, while preserving an explicit CODEX_HOME as authoritative. The regression will cover an ordinary WSL environment with one discoverable Windows Codex home and verify that service state/ownership resolves that home rather than the Linux fallback. I will also update the Codex-home structure note. This will not auto-migrate an already foreign service state; existing ownership protections remain fail-closed.

[Ingwannu]

Implemented in draft PR #1427: #1427

Service install-state ownership now uses the same WSL-aware Codex-home resolver as the runtime while preserving explicit CODEX_HOME authority and existing fail-closed foreign-state behavior. Focused WSL/service coverage, typecheck, privacy scan, and diff checks passed.

Leaving this issue open until independent review and integration into dev.