## Summary After upgrading from Codex CLI `0.117.0` to `0.118.0` on the same Linux machine and in the same repository, sandboxed commands in `/root/kiara` start failing before the actual command executes. The failing stderr is: ```text bwrap: Can't create file at /root/kiara/.codex: Permission denied ``` This causes even harmless read-only commands such as `pwd`, `rg`, `wc`, `id`, and `env` to fail inside the sandbox and then get re-run via approval escalation because the session uses `appro

0.118.0 regression: sandboxed commands fail with `bwrap: Can't create file at <repo>/.codex: Permission denied`

Resolved 💬 4 comments Opened Apr 4, 2026 by Manerba Closed Apr 4, 2026

Summary

After upgrading from Codex CLI 0.117.0 to 0.118.0 on the same Linux machine and in the same repository, sandboxed commands in /root/kiara start failing before the actual command executes.

The failing stderr is:

bwrap: Can't create file at /root/kiara/.codex: Permission denied

This causes even harmless read-only commands such as pwd, rg, wc, id, and env to fail inside the sandbox and then get re-run via approval escalation because the session uses approval_policy:"on-request".

Downgrading back to 0.117.0 restores normal behavior in a second session on the same machine.

Impact

Read-only commands fail before execution inside the sandbox.
The TUI keeps asking for approval to rerun commands outside the sandbox.
This breaks the expected no-prompt workflow in ordinary workspace-read and workspace-write scenarios.
The behavior is severe because it affects basic repo inspection, not just writes.

Environment

Host OS: Linux
Working directory: /root/kiara
Session sandbox policy: workspace-write
Approval mode in both working and failing sessions: on-request
Network access in session metadata: false
Subscription plan in session metadata: pro

A/B result

Same machine, same repository, same day, same approval mode:

0.118.0: fails with bwrap: Can't create file at /root/kiara/.codex: Permission denied
0.117.0: does not show this failure and proceeds normally

This strongly suggests a regression introduced in 0.118.0.

Reproduction

Start a Codex session in /root/kiara using CLI 0.118.0.
Run any simple sandboxed command such as:

pwd
rg --files docs/TODOS/P17
wc -l docs/TODOS/P17/TODO_P17_S7_TO_S9_IMPLEMENTATION_PLAN_V7.md

Observe that the command does not actually run.
Instead, the sandbox bootstrap fails with:

bwrap: Can't create file at /root/kiara/.codex: Permission denied

Because the session is approval_policy:"on-request", Codex then asks to rerun the command with escalation, which surfaces as repeated approval prompts.

Expected behavior

In a normal workspace-write sandbox, basic read-only commands should run without approval prompts.
If project-local .codex state is needed, Codex should create or handle it safely without breaking all sandboxed commands.
Upgrading from 0.117.0 to 0.118.0 should not turn ordinary read-only commands into approval requests.

Actual behavior

The sandbox bootstrap itself fails before command execution.
The failing path is /root/kiara/.codex.
The path does not exist, yet bwrap reports Permission denied while trying to create it.
The failure affects even commands that do not need writes.

Key observations

/root/kiara itself is writable enough to exist normally:

directory 755 kiara kiara /root/kiara

/root/kiara/.codex does not exist at the time of inspection:

stat: cannot statx '/root/kiara/.codex': No such file or directory

The regression is not explained by approval mode:

failing 0.118.0 session: approval_policy:"on-request"
working 0.117.0 session: approval_policy:"on-request"

The regression is not explained by plan tier:

working post-downgrade 0.117.0 session still reports plan_type:"pro"
failing 0.118.0 session also reports plan_type:"pro"

The post-downgrade 0.117.0 session files examined do not contain the same bwrap error.

Likely regression window

The most suspicious 0.118.0 change is the hardening around first-time project-local .codex handling:

0.118.0 release note:
Project-local .codex files are now protected even on first creation, closing a gap where the initial write could bypass normal approval checks.

This bug may be in or near that path, because the failing path is exactly the project-local .codex path under the workspace root.

There is also a 0.118.0 bwrap lookup fix, but that appears less likely to be the direct cause here because bwrap is already being launched and then fails later while trying to create /root/kiara/.codex.

Evidence

Failing 0.118.0 session metadata:

/root/.codex/sessions/2026/04/04/rollout-2026-04-04T14-48-55-019d588a-0c13-7b20-b3e1-a074405033d6.jsonl

Examples of failing tool calls in 0.118.0:

pwd
rg --files docs/TODOS/P17
wc -l docs/TODOS/P17/TODO_P17_S7_TO_S9_IMPLEMENTATION_PLAN_V7.md
id
env

Failing log excerpts:

/root/.codex/log/codex-tui.log
/root/.codex/sessions/2026/04/04/rollout-2026-04-04T04-51-35-019d5667-2b83-7310-9230-7574bd92e2f7.jsonl
/root/.codex/sessions/2026/04/04/rollout-2026-04-04T14-51-00-019d588b-f6cc-73f2-bcb3-ecedcb1a4043.jsonl

Working post-downgrade 0.117.0 session metadata:

/root/.codex/sessions/2026/04/04/rollout-2026-04-04T15-08-41-019d589c-24cb-7241-893a-efa23849c4da.jsonl
/root/.codex/sessions/2026/04/04/rollout-2026-04-04T15-14-23-019d58a1-5e3e-7c91-97e1-a66a64312314.jsonl

Suggested debugging directions

Inspect what changed in 0.118.0 around first-time project-local .codex creation and approval enforcement.
Verify whether Linux sandbox bootstrap now attempts to create a project-local .codex file or directory before command execution.
Verify whether the create path is being executed by a process or user that lacks permission due to namespace or mount setup, even though the target workspace itself is valid.
Confirm whether the .codex creation path is incorrectly treated as disallowed in workspace-write mode.
Confirm why a nonexistent /root/kiara/.codex yields Permission denied instead of a normal create or a clearer sandbox-policy error.