›_ Codex Issues
Codex Issues / #32733

Codex Desktop WSL mode forwards Windows TEMP/TMP via WSLENV, breaking pytest capture on DrvFS

Open 💬 0 comments Opened Jul 13, 2026 by Adamcf123

What version of the Codex App are you using?

  • Codex Desktop: 26.707.8479.0
  • Bundled Codex CLI: 0.144.2

What platform is your computer?

  • Windows: 10.0.22631.5699
  • WSL: 2.7.10.0
  • Distribution: Ubuntu 24.04
  • WSL kernel: 6.18.33.2-microsoft-standard-WSL2
  • Python: 3.13.14
  • pytest: 9.0.3
  • uv: 0.11.21

What issue are you seeing?

When Codex Desktop runs its app-server and task shell inside WSL, it forwards the Windows TEMP and TMP variables through WSLENV with path translation:

TEMP=/mnt/c/Users/<WindowsUser>/AppData/Local/Temp
TMP=/mnt/c/Users/<WindowsUser>/AppData/Local/Temp
WSLENV=...:TEMP/p:TMP/p:...
CODEX_INTERNAL_ORIGINATOR_OVERRIDE=Codex Desktop

As a result, Python selects the Windows-mounted DrvFS directory as its Linux temporary directory:

$ python -c 'import tempfile; print(tempfile.gettempdir())'
/mnt/c/Users/<WindowsUser>/AppData/Local/Temp

pytest's default output capture then fails during collection/cleanup because its temporary capture file is created on DrvFS rather than the WSL-native filesystem. The run misleadingly reports that no tests ran and ends with:

FileNotFoundError: [Errno 2] No such file or directory
  File "_pytest/capture.py", line 594, in snap
    self.tmpfile.truncate()

This is deterministic in the Codex Desktop WSL task environment.

What steps can reproduce the bug?

  1. On Windows, enable Codex Desktop WSL mode and open a repository stored in the WSL filesystem.
  2. In a Codex task shell, inspect the environment:

``bash
printf 'TEMP=%s\nTMP=%s\nWSLENV=%s\n' "$TEMP" "$TMP" "$WSLENV"
python -c 'import tempfile; print(tempfile.gettempdir())'
``

  1. In a Python repository containing pytest tests, run:

``bash
uv run pytest -q
``

  1. Observe that pytest reports no tests and fails while truncating its output capture temporary file.

Control experiments

The same 51-test suite produces these results:

Windows TEMP/TMP forwarded, default pytest capture
uv run pytest -q

Result: failure in _pytest/capture.py with FileNotFoundError; no tests complete.

Same forwarded TEMP/TMP, capture disabled
uv run pytest -q -s

Result:

51 passed in 7.90s
TEMP/TMP removed so Python uses WSL-native /tmp
env -u TEMP -u TMP uv run pytest -q

Result:

51 passed in 0.14s

Python also confirms the corrected temporary directory:

$ env -u TEMP -u TMP python -c 'import tempfile; print(tempfile.gettempdir())'
/tmp

The relevant filesystems differ:

/mnt/c  9p    aname=drvfs;path=C:\;...
/       ext4  ...

Evidence that Codex Desktop injects these variables

This is not a persistent Windows or WSL user configuration on the affected machine:

  • Windows user-level WSLENV: unset
  • Windows machine-level WSLENV: unset
  • Shell startup files: no TEMP, TMP, or WSLENV assignment
  • Ordinary WSL login shell: no TEMP, TMP, or Codex WSLENV list
  • Windows Terminal WSL shell: only WSLENV=WT_SESSION:WT_PROFILE_ID:
  • Codex Desktop WSL app-server: contains the full bridge list including TEMP/p:TMP/p, plus the translated Windows values shown above

What is the expected behavior?

When Codex Desktop launches a Linux app-server in WSL mode, Linux subprocesses should use a WSL-native temporary directory such as /tmp.

Codex Desktop should either:

  • omit Windows TEMP and TMP from the WSL environment bridge, or
  • replace them with a Linux-native temporary path before starting the WSL app-server and task subprocesses.

Windows temporary paths needed for specific Desktop integrations should be translated at those integration boundaries rather than becoming the general-purpose temporary directory for every Linux tool.

Related issues

  • #26149 records the same injected TEMP=/mnt/c/... and TMP=/mnt/c/... environment in Codex Desktop WSL mode, but reports plugin-cache latency rather than Linux tempfile breakage.
  • #13762 reports the same broader Windows-to-WSL environment propagation problem for CODEX_HOME/p.
  • #19791 concerns pytest temporary directories in the native Windows sandbox, but its ACL-based PermissionError is different from this WSL/DrvFS FileNotFoundError.

I searched open and closed issues for WSLENV, TEMP/p, TMP/p, pytest, FileNotFoundError, DrvFS, and /mnt/c temporary directories and did not find this exact failure mode.

View original on GitHub ↗