shell write denial vs apply_patch success on symlinked paths

Codex Version

• v0.117.0-alpha.13

Summary

There is still a path-resolution mismatch around writable paths: the shell tool may deny writes for a path while apply_patch can edit that same path.

This appears related to #14694 and the partial fix where sandbox write access was expanded to resolved paths without consistently resolving paths for permission checks/tooling behavior.

Current behavior

In the same session:

1. ~/bin/sudo resolves to a symlink target on another mount.
2. Shell write attempt fails with a sandbox/FS denial.
3. apply_patch successfully updates the same script path.

Concretely, I hit this when editing /home/rebroad/bin/cursor_safety_guard (with /home/rebroad/bin/sudo symlinked to it):

• Shell attempt (install) failed with:

not_writable
install: cannot create regular file '/home/rebroad/bin/cursor_safety_guard.test': Read-only file system

• Immediately after, apply_patch succeeded for /home/rebroad/bin/cursor_safety_guard.

This inconsistency caused the agent to incorrectly conclude write access was unavailable until switching to apply_patch.

Expected behavior

Path permission behavior should be consistent across tools:

• If shell writes are denied for a path, apply_patch should also be denied (or both should be allowed if policy allows that path).
• Permission checks should use the same canonicalization rules (including symlink resolution policy).

Why this matters

Agents make decisions based on prior tool failures. Inconsistent writeability signals cause incorrect escalation requests and wasted attempts.

Screenshot

<img width="881" height="545" alt="Image" src="https://github.com/user-attachments/assets/1942a965-f1b3-4fd7-a515-737573f37b5b" />