VS Code/WSL creates a persistent empty .codex file in workspace root

Resolved 💬 1 comment Opened Apr 8, 2026 by matteolegna Closed Apr 8, 2026

What version of the IDE extension are you using?

26.325.31654

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

When using Codex in VS Code on a Git repository opened through WSL2, an empty .codex file is created in the workspace root.

Observed behavior:

  • .codex appears as an untracked file in git status
  • the file is empty (0 bytes)
  • the file can reappear while actively using Codex
  • deleting it does not reliably solve the issue permanently

Deletion behavior seems context-dependent:

  • in a normal shell, rm .codex prompts because the file is write-protected
  • in the Codex execution environment, deletion may fail with:

rm: cannot remove '.codex': Device or resource busy

Relevant command output:

git status --short

?? .codex

ls -l .codex

-r--r--r-- 1 <user> <group> 0 Apr  8 11:37 .codex

file .codex

.codex: empty

uname -mprs

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

I also restarted both VS Code and WSL during debugging, but the file still reappeared during later Codex usage.

The project itself does not use .codex.

What steps can reproduce the bug?

  1. Open a Git repository in VS Code through Remote - WSL / WSL2
  2. Start using Codex in that workspace
  3. Let Codex inspect or edit the repository
  4. Check the repo root
  5. Run git status --short
  6. Observe that .codex appears as an untracked file
  7. Try deleting the file with rm .codex
  8. Continue using Codex and observe that the file may reappear

Additional note:

  • in some contexts, deleting the file from the Codex execution environment fails with Device or resource busy
  • in a normal shell, deletion prompts because the file is write-protected

What is the expected behavior?

Codex should not create an untracked file in the repository root.

If such a file is needed internally, it should ideally be stored outside the project root or handled in a way that does not pollute git status.

Additional information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗