Linux sandbox: bwrap "Bad file descriptor" when a workspace root contains two or more denied files

Codex aborts at startup when a workspace root contains two or more files matched by deny filesystem rules. One denied file works; two or more always fail.

bwrap: Can't write data to file <workspace>/one.key: Bad file descriptor

Repro

Isolated CODEX_HOME, dummy files only, no real secrets.

default_permissions = "test"
[permissions.test.network]
enabled = false
[permissions.test.filesystem]
":minimal" = "read"
"<path to installed @openai package dir>" = "read"
[permissions.test.filesystem.":workspace_roots"]
"." = "write"
"**/*.key" = "deny"
"**/.env.local" = "deny"

codex sandbox -P test -C <workspace> -- /bin/true

Also observed

• Same on 0.153.4 and 0.152.1, so not a recent regression. Linux x86_64, bundled bwrap.
• Independent of exact paths vs globs, subdirectories, read-only vs writable workspace root, and glob_scan_max_depth.
• Denying a directory containing the same files works and correctly blocks reads.
• -c use_legacy_landlock=true is not a workaround: permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock.

Impact

Any real project with two or more .env/key files cannot start Codex without removing the very rules that keep those files unreadable. The same failure occurs during normal TUI startup while loading AGENTS.md.

Related but distinct: #40433 (malformed or missing path rules).

Start at the codex sandbox entry point and reproduce the Linux failure with the provided TOML rules and /bin/true command. Trace the bundled bwrap setup for multiple denied files, then verify that two or more denied files allow startup while remaining unreadable, including during normal TUI startup.