What version of Codex CLI is running?
codex-cli 0.153.4. Only this version was tested.
What subscription do you have?
Not included. This report is limited to a local codex sandbox command.
Which model were you using?
Not applicable to the synthetic test; no model request was made.
What platform is your computer?
Linux, running the CLI inside an already restricted task executor.
What terminal emulator and version are you using (if applicable)?
Not applicable to this non-interactive invocation.
Codex doctor report
Not included; only the sanitized command shape, error, and synthetic test results are shared here.
What issue are you seeing?
A nested codex sandbox invocation failed during preparation, before the Python child test started, with exit status 101:
failed to open synthetic bubblewrap mount registry lock /tmp/codex-bwrap-synthetic-mount-targets-1000/lock: Read-only file system (os error 30)
Observed in the enclosing executor:
/tmp was writable.- The registry directory was a separate read-only mount.
- The process UID and registry owner were both 1000, and owner-write mode bits were present. This was therefore not simply a missing owner-write permission.
What steps can reproduce the bug?
These are the observed test steps, not a complete standalone reproducer. The exact permission profile and outer executor configuration are not included.
- Run a baseline test using only synthetic files: all four path reads succeeded (4/4), exit status 0.
- Run the sandboxed version once, using this sanitized command shape:
codex sandbox -P reviewed-profile --include-managed-config -C synthetic-folder -- /usr/bin/python3 synthetic-test
reviewed-profile, synthetic-folder, and synthetic-test are placeholders.
3. Observe the registry-lock error above and exit status 101 before the child test runs.
Because the child did not run, this result does not establish whether the intended file protections would pass or fail. No personal-data test or bypass was attempted.
What is the expected behavior?
A supported way to run this nested sandbox while preserving the outer executor's restrictions, or an actionable diagnostic explaining that the configuration is unsupported.
What is the supported remediation? If this failure is already fixed, which release contains the fix?
Additional information
Source observations from the 0.153.4 tag:
- linux_run_main.rs opens the registry lock with read/write/create options.
- bwrap.rs protects the registry with a read-only bind mount where a writable bind exposes it.
This is consistent with a nested sandbox-preparation conflict, but the exact outer policy and creator of the observed read-only mount are unknown. These observations do not establish a confirmed root cause.
Related: #39944 reports a mkdir failure when slash_tmp is denied. Here /tmp was writable and the failure was opening an existing registry lock on a separate read-only mount.
What version of Codex CLI is running?
codex-cli 0.153.4. Only this version was tested.
What subscription do you have?
Not included. This report is limited to a local
codex sandboxcommand.Which model were you using?
Not applicable to the synthetic test; no model request was made.
What platform is your computer?
Linux, running the CLI inside an already restricted task executor.
What terminal emulator and version are you using (if applicable)?
Not applicable to this non-interactive invocation.
Codex doctor report
Not included; only the sanitized command shape, error, and synthetic test results are shared here.
What issue are you seeing?
A nested
codex sandboxinvocation failed during preparation, before the Python child test started, with exit status 101:Observed in the enclosing executor:
/tmpwas writable.What steps can reproduce the bug?
These are the observed test steps, not a complete standalone reproducer. The exact permission profile and outer executor configuration are not included.
reviewed-profile,synthetic-folder, andsynthetic-testare placeholders.3. Observe the registry-lock error above and exit status 101 before the child test runs.
Because the child did not run, this result does not establish whether the intended file protections would pass or fail. No personal-data test or bypass was attempted.
What is the expected behavior?
A supported way to run this nested sandbox while preserving the outer executor's restrictions, or an actionable diagnostic explaining that the configuration is unsupported.
What is the supported remediation? If this failure is already fixed, which release contains the fix?
Additional information
Source observations from the 0.153.4 tag:
This is consistent with a nested sandbox-preparation conflict, but the exact outer policy and creator of the observed read-only mount are unknown. These observations do not establish a confirmed root cause.
Related: #39944 reports a mkdir failure when
slash_tmpis denied. Here/tmpwas writable and the failure was opening an existing registry lock on a separate read-only mount.