Starting a thread in a project without .codex leaves behind an empty .codex file

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.

also seeing this with windows vs code extension version 26.325.31654

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

Also see this issue in Linux Codex CLI version 0.118.0

plus one, I will close my actual report,

I just want to add that we cannot leverage that file at all, if I could save instructions in it at least it woudl provide value to my repositary.

Additional data point from Linux CLI that seems to support the root-cause hypothesis in this issue.

I opened #16790 with a more specific A/B repro and exact failing stderr.

Why I think this is strongly related to this issue's root cause:

• same machine / same repo / same approval mode
• 0.117.0 works
• 0.118.0 fails
• in both working and failing sessions: approval_policy:"on-request"
• in both working and failing sessions: plan_type:"pro"

In the failing 0.118.0 case, the sandbox bootstrap fails before the command runs with:

bwrap: Can't create file at /root/kiara/.codex: Permission denied

Important detail: /root/kiara/.codex does not exist outside the sandbox when inspected. So this is not just "Codex left behind an empty .codex file"; on this host the same first-time CWD/.codex handling seems to fail hard enough to break all sandboxed commands.

Even these fail before execution in 0.118.0:

• pwd
• rg --files ...
• wc -l ...
• id
• env

Host context from the repro:

• /root is 701 root:root
• /root/kiara is 755 kiara:kiara
• host-side Codex process is uid=0(root) gid=0(root)

My current guess is that 0.118.0 changed the ordering or execution context of first-time project-local .codex protection/creation, and on some Linux setups that now turns the .codex protection path into a hard EACCES during sandbox bootstrap.

Issue with exact logs and A/B details: #16790

This is really annoying as I either need to delete this empty file manually or update .gitignore in every repository I work with Codex 🙄.

This is really annoying as I either need to delete this empty file manually or update .gitignore in every repository I work with Codex 🙄.

Even more annoying we cant leverage this file for instructions or anythign, it serves us no purpose why would it be on our repo ?

Also I shoudlnt have to edit my gitignore for each plugin that decides it wants to commit a file in the root of my repo.

I don't think this should be labeled Windows/WSL, it happens for me on my MacBook and on my Linux desktop, using codex-cli >=0.118.0 from npm. I've pinned to 0.117.0 for now.

Looks like PR https://github.com/openai/codex/pull/16930 is meant to address this issue

Silly silly weirdness...

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.

For me, the Codex CLI does create an empty .codex folder. It creates when executing a command such as ls.

• Version: codex-cli 0.120.0
• OS: Arch Linux x86_64
• Terminal: alacritty 0.16.1

are there any updates as of 2026 April 16?

are there any updates as of 2026 April 16?

Are you posting two days in the future? 😄

What's the point of whining in a comment? Subscribe to the thread and you'll be alerted. Stop posting useless comments, it annoys those who have subscribed to the thread. Thanks

In case it's useful to anyone, as a workaround until this issue is fixed, I'm using the following wrapper script around codex to automatically create .codex/.gitignore with * as its only contents, which obviously doesn't prevent .codex from being created but at least prevents Git from worrying about it:

import os
import sys
from pathlib import Path

dot_codex = Path(".codex")
if not dot_codex.exists() and Path(".git").exists():
    dot_codex.mkdir()
    (dot_codex / ".gitignore").write_text("*\n")
os.execvp("codex", ["codex", *sys.argv[1:]])

@samestep You can instead just create a .codex folder. An empty folder won't get tracked by git.

Could this be related to https://github.com/openai/codex/issues/15764 ? Maybe the file .codex is supposed to be used for file level locking/syncronization between agent processes and just the cleanup is broken?

I'm also seeing this issue.

Still an issue in codex-cli 0.121 and also an issue when using codex natively in Linux Fedora 43 KDE Konsole

Have the same problem in vscode. Ubuntu 24.04, codex: 26.415.20818

Can confirm with codex-cli 0.120.0 on Ubuntu 24.04.3 LTS.

This also happens with the Codex Windows App 26.421.11020.

This looks like an unintended WSL + bubblewrap side effect, not intentional project config creation.

Codex deliberately protects a missing top-level ./.codex path so project-local metadata cannot be created implicitly (codex-rs/protocol/src/permissions.rs:1334-1340). In the Linux sandbox path, missing protected paths are handled by finding the first non-existent path component and binding /dev/null onto it (codex-rs/linux-sandbox/src/bwrap.rs:807-815, 966-994).

On WSL, especially for workspaces under /mnt/c/..., that strategy appears to materialize a host-side empty file named .codex in the project root. So the protection logic itself seems intentional, but the host filesystem artifact does not.

The Windows sandbox path does not look like the source of this behavior, because it only applies protection when .codex already exists as a directory (codex-rs/windows-sandbox-rs/src/workspace_acl.rs:20-26).

Pragmatic fix direction

The current protection semantics should stay, but missing protected paths should not leave host-side artifacts behind.

Possible fix:

• When the protected path does not exist, do not bind /dev/null directly onto the host path.
• Instead, create the blocker only inside the sandbox mount namespace, or redirect the bind target to an internal sandbox-only placeholder path.
• At minimum, add a regression test for WSL-mounted workspaces that verifies starting a thread in a project without .codex does not leave behind a host-side .codex file.

why is this taking so long to fix ?

Getting a little ridiculous on how long its taking to fix this issue. Super annoying, am staying on a older version to avoid the problem.

Just started happening to me after updating to 0.124.0 .....

I created this branch that takes care of the .codex issue. It deletes the blank ones that already got created and it stops making them.

https://github.com/openai/codex/compare/main...gjs278:fix-dot-codex-empty-file?expand=1

https://github.com/gjs278/codex/tree/fix-dot-codex-empty-file

this is synced up with 0.125.0

Reminder that PR #16930 exists already

Happens on codex-cli version 0.125.0 as well.

codex-cli 0.125.0 the same

Update: I no longer recommend the shell-wrapper workaround I posted here earlier.

The wrapper avoided the empty-file symptom by creating a real .codex/ directory before launching the CLI. That is still a project-root filesystem side effect, and it can make accidental commits more likely later if files appear under .codex/.

For CLI users who only want to avoid accidentally committing the artifact while waiting for an upstream fix, a lower-risk local workaround is to use a user-level Git ignore rule instead:

git config --global core.excludesfile ~/.gitignore_global
printf '\n.codex\n' >> ~/.gitignore_global

This does not fix Codex creating the artifact, and it does not help non-Git directories. It only makes Git ignore .codex files/directories across local repositories on that machine, without modifying each repository's tracked .gitignore.

If a repository intentionally wants to track .codex content later, it can still be added explicitly with:

git add -f .codex

The actual fix should still be in Codex/bwrap so starting a thread does not create host-side project artifacts in the first place.

is this issue still being tracked ?

Still facing this issue. WSL Ubuntu 24.04 + Codex CLI v0.125.0 via npm.

Empty .codex file created...

Please fix

still facing this issue of using codex cli and then it creates a .codex file in the directory of work

https://github.com/openai/codex/pull/16930 was closed automatically due to not having updates, but it solves exactly this issue @etraut-openai

Additional observation: in Codex CLI 0.126.0-alpha.8 on Linux, the empty .codex file also appeared as a read-only mount inside the Codex tool sandbox:

findmnt -T .codex
/home/.../repo/.codex /dev/nvme0n1p5[/home/.../repo/.codex] ext4 ro,nosuid,nodev,relatime

rm .codex failed with:
Device or resource busy

Escalated/host namespace did not see the same mount, suggesting it exists only inside the Codex sandbox namespace.

Seems to be fixed? Or at least it's not happening to me anymore on version v0.128.0.

I'm confirming that this issue no longer seems to happen with VS Code Codex extension v26.506.31421.

This bug has been fixed.

It seems codex don't create a .codex file, but it now creates .codex FOLDER and .agents folder when running the job. Sometimes they won't be deleted when the task is finished.