v0.121.0: apply_patch fails with use_legacy_landlock=true and prompts sandbox retry for workspace edits

What version of Codex CLI is running?

codex-cli 0.121.0

Which model were you using?

gpt-5.4

What platform is your computer?

Linux

What issue are you seeing?

With use_legacy_landlock = true, normal workspace edits regress in 0.121.0.

The edit target is inside the current repository and is readable/writable under the legacy landlock sandbox. Simple shell commands in the sandbox succeed, and direct write smoke tests also succeed. But when Codex goes through the file-change / apply_patch path, it fails before completing the edit through the normal mechanism.

The exact error I reproduced is:

Failed to read file to update /path/to/repo/.codex-smoke.txt: fs sandbox helper failed with status exit status: 101: thread 'main' (...) panicked at linux-sandbox/src/linux_run_main.rs:395:9:
split sandbox policies requiring direct runtime enforcement are incompatible with --use-legacy-landlock

After that, Codex may ask:

Reason: command failed; retry without sandbox?

This seems related to #17674 ("Route apply_patch through the environment filesystem"), which already notes:

• approval/retry behavior still need explicit scrutiny for delete/update flows

This looks like a concrete Linux regression for the use_legacy_landlock = true path.

What steps can reproduce the bug?

1. Run Codex 0.121.0 on Linux in an environment where legacy landlock is required.
2. Put this in ~/.codex/config.toml:

[features]
use_legacy_landlock = true

1. In a Git repo, create a test file:

.codex-smoke.txt
foo

1. Run:

codex exec --json -C /path/to/repo "Edit .codex-smoke.txt in the current repository by replacing the exact text 'foo' with 'bar'. Do not touch any other file."

1. Observe:

• the initial shell read succeeds
• the file-change / apply_patch step fails with the panic above
• Codex may then ask to retry without sandbox

What is the expected behavior?

One of these should happen:

1. apply_patch should work when use_legacy_landlock = true, or
2. the apply_patch path should detect that this sandbox/helper combination is unsupported and use a compatible in-sandbox fallback without presenting a misleading sandbox-bypass prompt for normal workspace edits

Additional information

• Related older Linux sandbox issue: #17337
• Related broad regression report: #14936
• I also directly verified that the legacy landlock sandbox itself is not generally broken:

codex sandbox linux -c features.use_legacy_landlock=true --full-auto -- /bin/sh -lc 'pwd'
codex sandbox linux -c features.use_legacy_landlock=true --full-auto -- /bin/sh -lc 'touch /tmp/codex-legacy-smoke && ls -l /tmp/codex-legacy-smoke'

Both of those succeed.