WSL: starting a thread in a project without .codex leaves behind an empty .codex file

[aprendendo-codex]

What version of the IDE extension are you using?

26.325.31654

What subscription do you have?

pro

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

When Codex runs under WSL (both IDE plugin and Codex App) and starts a thread in a project that does not already contain a .codex/ directory, it leaves behind an empty file named .codex in the project root.

This looks like a sandbox side effect rather than intentional project config creation.

Environment

• Platform: WSL
• Sandbox path: Linux sandbox / bubblewrap path
• Repro date: 2026-03-28

Actual behavior

An empty file named .codex appears in the project root.

What steps can reproduce the bug?

Reproduction

1. Create or use a project directory that does not contain .codex:

   mkdir repro && cd repro
   ls -la

2. Start a Codex thread in that directory using either VS Code IDE plugin or Codex App, with WSL enabled. For example: "explain this codebase"
3. After the thread starts, inspect the directory:

   ls -la

Notes

This only reproduces when the project does not already have a .codex/ directory.

What is the expected behavior?

Expected behavior

No filesystem artifact should be created in the host project root merely from starting a thread.

If Codex wants to protect ./.codex as reserved metadata, that should happen without creating a host-side empty file.

Additional information

Suspected root cause

The policy layer intentionally treats a missing top-level CWD/.codex as a protected path so the agent cannot create project metadata without approval.

That part seems intentional:

• codex-rs/protocol/src/permissions.rs
• default_read_only_subpaths_for_writable_root(...) includes missing CWD/.codex when protecting the cwd root

Relevant code:

• codex-rs/protocol/src/permissions.rs:1128
• codex-rs/protocol/src/permissions.rs:1133

Then the Linux sandbox / bubblewrap path appears to enforce non-existent protected paths by mounting /dev/null on the first missing component:

Relevant code:

• codex-rs/linux-sandbox/src/bwrap.rs:459
• codex-rs/linux-sandbox/src/bwrap.rs:569

The comment there says:

• for a non-existent protected path, find the first missing component
• mount /dev/null on it to prevent creation

In practice, when the missing component is ./.codex, this seems to leave behind an empty file .codex on the host filesystem under WSL.

Why this is a problem

• It modifies the user’s project just by starting a thread
• It creates a confusing artifact that looks like a project config marker
• It is especially surprising in repos where .codex is not being used intentionally

Suggested fix

Keep the protection semantics, but avoid materializing a host-side file for a missing protected path.

Possible directions:

1. Change the bubblewrap strategy for missing protected paths so it does not target the host path directly when the path does not yet exist.
2. Create the blocker only inside the sandbox mount namespace rather than on the host filesystem.
3. Add a regression test that asserts:
   • starting from a project root with no .codex
   • building sandbox args / launching the sandbox
   • does not leave a host-side .codex file behind

Relevant files

• codex-rs/protocol/src/permissions.rs
• codex-rs/linux-sandbox/src/bwrap.rs

Extra context

This does not look like intentional .codex project folder creation.

It looks like:

• intentional protection of missing .codex
• plus an unintended bubblewrap side effect that materializes .codex as an empty file

[vegbom]

Also seeing this on Linux VS Code Extension ver 26.325.31654. (This issue Does not happen when using codex CLI).

Rolled back to ver 26.325.21211 and there is no such issue.

[jesse-black]

also seeing this with windows vs code extension version 26.325.31654

[jeremiah-k]

This just started happening for me after updating the CLI to v0.118.0 (Linux Mint 22.3). It wasn't an issue in v0.117.0