Workspace edits always require approval when project `.codex` is a symlink inside writable root. (Linux Bubblewrap sandbox.)

What version of Codex CLI is running?

0.128.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.17.0-1014-nvidia aarch64 aarch64

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

_No response_

What issue are you seeing?

Ordinary workspace edits inside a writable workspace require manual approval when the project’s .codex directory is a symlink into the writable root. (Previously, with use_legacy_landlock = true, this was not a problem with an identical configuration.)

The TUI shows an approval prompt like:

Would you like to make the following edits?
Reason: command failed; retry without sandbox?

<img width="1290" height="528" alt="Image" src="https://github.com/user-attachments/assets/34b59679-c015-49ce-963a-e6d00de0fb06" />

The edit target is inside the project’s writable workspace.

If I approve the prompt, the patch applies successfully. The transcript records a normal apply_patch call and a successful patch_apply_end, but does not appear to record the underlying reason that the approval prompt was required. This makes normal editing impractical because every ordinary workspace edit requires manual approval, even though sandbox_mode = "workspace-write" is configured.

This may be related to #20716, where the same project layout causes non-whitelisted sandboxed commands to panic because .codex is a symlink into the writable root.

What steps can reproduce the bug?

1. Create a project with .codex as a symlink to a directory inside the writable workspace, e.g.: .codex -> .auxiliary/configuration/coders/codex.
2. Configure .codex/config.toml with:

```toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "user"
trust_level = "trusted"

[features]
guardian_approval = false
```

1. Start Codex CLI in that project.
2. Ask Codex to make a harmless edit inside the writable workspace.
3. Observe that the TUI asks for approval with: Reason: command failed; retry without sandbox?

What is the expected behavior?

Edits inside the writable workspace should apply without requiring approval when sandbox_mode = "workspace-write" and approval_policy = "on-request".

If approval is required, the TUI and/or transcript should expose the actual reason rather than the generic: command failed; retry without sandbox?.

Additional information

A related lower-level sandbox issue was filed as #20716.

In this session, an approved edit produced transcript entries like:

  {
    "type": "custom_tool_call",
    "name": "apply_patch",
    "input": "*** Begin Patch\n*** Add File: .auxiliary/scribbles/codex-approved-edit-probe.txt\n+approved edit probe\n*** End Patch\n"
  }

followed by:

  {
    "type": "patch_apply_end",
    "stdout": "Success. Updated the following files:\nA .auxiliary/scribbles/codex-approved-edit-probe.txt\n",
    "stderr": "",
    "success": true,
    "status": "completed"
  }

So the patch itself is valid and succeeds once approval is granted. The problem is that the edit is unnecessarily routed through approval in the first place.

The host Bubblewrap/AppArmor setup has already been verified according to the official Codex sandboxing instructions. E.g., codex sandbox linux /bin/true succeeds from /tmp; the issue appears specific to this project layout.