›_ Codex Issues
Codex Issues / #37225

Windows: Codex leaves orphaned Q*.tmp temp files in the working directory (not cleaned up)

Open 💬 4 comments Opened Aug 6, 2026 by freedally
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, Codex (CLI/Desktop) leaves orphaned Q<8-hex>.tmp files directly in the current working directory / project root and also accumulates the same pattern in %TEMP%. These temp files are never cleaned up.

  • Project working directory: 100+ files appeared while running Codex shell commands.
  • %TEMP%: 7000+ files of the same Q*.tmp format accumulated (mostly from 2026-08-03/04 while using Codex CLI).

The files match the Rust tempfile crate naming style (Q prefix + random hex + .tmp), and codex.exe embeds nix_tempfile::handle::Writable plus sandbox tmpdir/slash_tmp path concepts.

Reproduction / Evidence

  1. Control experiment: while no shell command was executed for 60 s, the tmp count stayed constant (118 -> 118). As soon as Codex shell commands ran, the count grew (105 -> 118 -> 123).
  2. Not caused by a version update: this issue was already observed the day before this report, independent of any codex-command-runner update on the reporting day. The temp files are written to the working directory instead of %TEMP%.
  3. File contents share a common template (magic bytes scz + shared prefix), i.e. they are produced by the same writer.
  4. Files are ignored by .gitignore (*.tmp) so they do not pollute git status, but they still pollute the workspace.

Expected behavior

  • Temp files should be written to the OS temp directory (%TEMP%), not the current working directory / project root.
  • Temp files should be cleaned up automatically after the command/process exits (or at least bounded retry/cleanup), instead of accumulating unboundedly.

Related issues

  • #36428 (feature request: clean up temp files created by codex under /tmp on exit)
  • #33311 (Windows Codex Desktop repeatedly leaves thousands of temp files in %TEMP%)

Environment

  • Windows 10/11, Codex CLI / Desktop (API-key session)

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 22 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #36428

Powered by Codex Action

freedally · 22 days ago

To clarify the relationship with #36428: they are related but address different problems.

  • #36428 is a feature request about cleaning up temp files under /tmp on exit (cleanup lifecycle).
  • The core problem here is different: why are the temp files being written to the working directory instead of %TEMP% in the first place? #36428 does not cover this aspect.

On this machine the temp files are created in the project root (the current working directory) and accumulate there, polluting the workspace. Even a proper cleanup-on-exit would not fix the wrong placement. This report is specifically about:

  1. Temp files being written to the wrong location (working directory instead of %TEMP%), and
  2. The missing automatic cleanup.

Both are needed to fully address the issue.

LIghtJUNction · 18 days ago

I implemented a candidate fix for the Windows temporary-file leak:

  • Every sandbox command gets an OS-temp command directory under %TEMP%.
  • TEMP, TMP, and TMPDIR are rewritten case-insensitively so child processes cannot fall back to the project working directory.
  • The command-owned directory is cleaned with retries after process, pipe, runner, and capture exits; stale owned directories are cleaned safely on the next command.
  • PR: https://github.com/LIghtJUNction/codex/pull/1
  • Commit: 4c9440e8d

My account cannot create the upstream PR because it has read-only permissions on openai/codex. Please review the fork PR or cherry-pick the commit.

tongflau-dongzhu · 9 days ago

The fork PR above (and #36428's cleanup-on-exit) is the right endgame — I won't argue that a fix isn't the real answer, and nothing I'm sharing is meant as a replacement for that work.

I'm commenting because the project-root part of this is the exact gap I work on from the outside: the working directory is the one thing every tool and every future agent session shares, and once Q*.tmp files land there, nothing in the workspace distinguishes them from real work. I maintain workspace-metabolism, a zero-dependency Python CLI where one policy file decides what each path is worth; cleanup moves items to a recycle area instead of deleting (dry-run by default), and every action lands in a hash-chained journal with exact rollback.

For the 100+ files already in the project root, the read-only audit is a ~30-second check on a copy of a workspace — no writes unless you explicitly ask:

git clone https://github.com/metabolism-tools/workspace-metabolism.git
cd workspace-metabolism
python examples/demo.py
# or read-only on your own workspace copy:
PYTHONPATH=src python -m workspace_metabolism audit --root /path/to/copy

It's early days (v0.2, no external users yet), so I'm specifically looking for feedback on whether audit → recycle → rollback is a useful middle step for residue that's already accumulated and unreferenced, or whether a plain delete-all is the only honest answer until the upstream fix ships. Either answer is useful.