Empty `.codex` file created at repo root

Resolved 💬 3 comments Opened Mar 31, 2026 by howardjohn Closed Apr 2, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.118.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux

What terminal emulator and version are you using (if applicable)?

Alacritty + Tmux

What issue are you seeing?

When I use codex I get a .codex file (not folder) in the root of my repo. This file is empty and seems to serve no purpose (other than to annoy me 🙂 ). This seems new since 0.118

What steps can reproduce the bug?

run codex, ls -a

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

#16088
#16247
#16336

Powered by Codex Action

howardjohn · 4 months ago

https://github.com/openai/codex/issues/16088

teebs4140 · 4 months ago

I can reproduce this on native Ubuntu/Linux as well, and I have some A/B evidence that may help narrow the cause.

Environment:

Codex CLI: 0.118.0
Platform: Ubuntu Linux on an Azure VM
bubblewrap: /usr/bin/bwrap version 0.9.0

Observed artifact:

repo-root file named .codex
regular file, not directory
zero bytes
mode 0444
untracked in git

Example metadata from stat .codex immediately after creation:

File: .codex
Size: 0
Access: (0444/-r--r--r--)
Birth: 2026-04-02 16:13:46 +0000

What I tested:

1. When Linux sandboxing is broken, the file does not appear

With Ubuntu/AppArmor restrictions in the failing state:

$ codex sandbox linux -- /bin/true
bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

In that state, Codex work that failed early because the local sandbox was broken did not create .codex in the repo.

2. When Linux sandboxing works, `.codex` appears

I reproduced the same .codex creation under two different ways of making sandboxing work:

A. Targeted AppArmor workaround

After installing a path-scoped AppArmor exception for the native Codex binary:

$ codex sandbox linux -- /bin/true
# succeeds

Then real Codex work in a repo caused .codex to appear.

B. Global sysctl workaround instead of AppArmor profile

I removed the AppArmor profile, then used the broader workaround:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

After that, sandboxing worked again and the same .codex file was created during Codex work.

This seems important: the artifact is not tied to the AppArmor profile workaround itself. It happens under both workaround methods. The common factor is that the Linux sandbox path is functional.

3. It is not just `/review`

I first noticed it with /review, but after more testing I confirmed that once sandboxing is functional, any real local Codex work path seems able to trigger it.

4. It is not every Codex invocation

Some shallow invocations did not reproduce it, for example trivial codex exec tests. The file appeared when Codex started doing actual repo-local work.

Likely interpretation

This looks like a native Linux variant of the same general bug described in #16088:

when sandboxing is operational,
a repo-local protected .codex path is being materialized incorrectly as a host-side empty file,
instead of remaining absent or becoming a real .codex/ directory only when explicitly intended.

The strongest native-Linux signal from my side is:

broken sandbox: no .codex
working sandbox via targeted AppArmor workaround: .codex appears
working sandbox via sysctl workaround: .codex appears

So the trigger seems to be successful local Linux sandbox execution plus real repo-local work, not the specific workaround used to enable sandboxing.