apply_patch fails when ~/.codex is a symlinked directory

[rebroad]

Summary

When ~/.codex is a symlink to another partition, apply_patch fails in the sandbox. This started after the memories feature was introduced (it appears to create/use ~/.codex/memories).

Version

codex v0.115.0-alpha.19

Repro

1. Make ~/.codex a symlink to another partition (e.g. /mnt/p8/@home/rebroad/.codex).
2. Run any apply_patch operation.

Actual

bwrap errors out during sandbox setup:

bwrap: Can't mkdir /home/rebroad/.codex/memories: No such file or directory

Earlier it also failed with:

bwrap: Can't bind mount /oldroot/mnt/p8/@home/rebroad/SunOS on /newroot/home/rebroad/SunOS: Unable to mount source on destination: No such file or directory

Expected

apply_patch should work regardless of whether ~/.codex is a symlink. The sandbox setup should resolve symlinks or create needed paths inside the sandbox appropriately.

Notes

This appears to have regressed after the new memories feature that uses ~/.codex/memories.
The commit that introduced create_dir_all(&memories_root) and added the memories root to workspace-write is:
f72ab43fd193b31208cd3c306293b1b71a52a709 (2026-03-04 13:00:26 +0000, "feat: memories in workspace write (#13467)").

There may also be a related regression in Linux sandboxing around symlink handling in bubblewrap:
774965f1e8691f1a0568fb801f24b15553e5e6cd (2026-03-12 10:56:32 -0700, "fix: preserve split filesystem semantics in linux sandbox (#14173)").
That change added explicit symlink detection in bwrap mount setup, which may cause symlinked writable roots (like ~/.codex) to be masked.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Failed to apply patch: bwrap: Can't mkdir .codex/memories: No such file or directory #14261
• bwrap: Can't mkdir .codex/memories: No such file or directory #13635
• bwrap sandbox bind fails with symlinked TMPDIR #14672

Powered by Codex Action

[etraut-openai]

I think this is a duplicate of #13635

[rebroad]

I think this is a duplicate of #13635

it is, but that one is closed, and this is still an issue

[etraut-openai]

Ah, good point. Reopening this one.

[yitoli-c]

To give some example impacts from this error: #14261, namely:

1. users wary of "full-access" mode will see codex stuck in trying to fix the observed error, or spent many turns trying to use alternative approaches to apply patch
2. with multi_agent, even if main agent has "full-access", sub-agent by default does not have "full-access", so it can stuck in the loop trying to fix the observed apply_patch error first, and gave up the assigned task eventually.

Symlink ~/.codex seems to be an important common factor here. Unlink ~/.codex is not an option due to disk quota setup we have.

[rebroad]

confirmed still an issue on v0.115.0-alpha.23