Long-running (idle?) codex sessions have bwrap failures

Resolved 💬 4 comments Opened Mar 16, 2026 by RadixSeven Closed Mar 17, 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.114.0

What subscription do you have?

Enterprise

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 4.18.0-553.100.1.el8_10.x86_64 x86_64 x86_64

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

SecureCRT 9.3.2 (x64 build 2978)

What issue are you seeing?

I left the session and returned after more than 12 hours (I'm not sure how long it was), and bwrap started to give errors. The thread I uploaded is for a different set of errors because the error messages were no longer displayed after resuming, but the first time I experienced this, I recorded the errors elsewhere:

• Ran pwd
  └ bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/home/ ostapchu": Invalid argument
• Ran git status --short
  └ bwrap: Can't bind mount /oldroot/ on /newroot/: Unable to apply mount flags: remount "/newroot/home/ ostapchu": Invalid argument

I solve this by exiting and resuming, which makes it more of an annoyance. But I expect that if I had a task that ran for 24 hours, it would trigger this and the task would start to encounter spurious errors and confuse the LLM.

What steps can reproduce the bug?

Start a codex session using bwrap sandboxing
Run a simple prompt that runs a tool that accesses the filesystem (it should succeed)
Leave for 24 hours
Run another prompt that runs a tool that accesses the filesystem - it should fail

Uploaded thread: 019ce3b7-623a-7180-a4fd-de9a4f82f097

What is the expected behavior?

The second access to the filesystem should be OK.

Additional information

The working directory for this conversation (and everything I do) is outside my home directory and on a local drive. However, the home directory is NFS-mounted. Oddly, the error messages talk about attempting to mount another user's home directory. This problem has happened twice now, and it was a different user's directory each time. The server I work on is shared by several hundred developers.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 5 months ago

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

#14694
#14715
#14672

Powered by Codex Action

viyatb-oai contributor · 5 months ago

@RadixSeven can you check if 0.115 fixes this? it was fixed in https://github.com/openai/codex/commit/9060dc7557848feb80a0fca612b9b1037c2ec217

RadixSeven · 5 months ago

can you check if 0.115 fixes this? it was fixed in https://github.com/openai/codex/commit/9060dc7557848feb80a0fca612b9b1037c2ec217

The issues linked to that PR look different from what I experienced. But it's quite plausible that they're related.

I've started a new session with 0.115, I'll check back tomorrow. with the results.

$ http_proxy= nice codex -c features.use_linux_sandbox_bwrap=true
WARNING: failed to clean up stale arg0 temp dirs: Directory not empty (os error 39)
╭───────────────────────────────────────╮
│ >_ OpenAI Codex (v0.115.0)            │
│                                       │
│ model:     gpt-5.4   /model to change │
│ directory: /export/home/my-username/workingdir  │
╰───────────────────────────────────────╯

  Tip: New Use /fast to enable our fastest inference at 2X plan usage.


› Please run the `pwd` command.


• Running pwd in the repository root to report the current working directory.

• Ran pwd
  └ /export/home/my-username/workingdir

─────────────────────────────────────────────────────────────────────────────────────────────────────────

• pwd returned /export/home/my-username/workingdir.
›

RadixSeven · 5 months ago

I just tried it more than 24 hours after I started that session and both pwd and git status worked fine.