macOS: projectless chats default to ~/Documents/Codex, which is a symlink under OneDrive Known Folder Move, so the sandbox refuses every command #45485

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT for macOS 26.903.71938 (8576), bundled codex-cli 0.153.4

What subscription do you have?

ChatGPT Enterprise (workspace Owner; Intune-managed fleet)

What platform is your computer?

macOS 26.6.2 (arm64), Microsoft Intune + OneDrive Known Folder Move

What issue are you seeing?

On enterprise Macs with OneDrive Known Folder Move, ~/Documents (and ~/Desktop) are symlinks:

~/Documents -> /Users/<user>/Library/CloudStorage/OneDrive-<Tenant>/Documents

The desktop app starts every projectless chat with a workspace root under ~/Documents/Codex/<date>/<slug> (visible in ~/.codex/.codex-global-state.json under thread-workspace-root-hints and thread-projectless-output-directories). Seatbelt preparation then rejects that root, so no command can run in any projectless chat, including plugin skills that shell out:

exec_command failed: CreateProcess { message: "UnsupportedOperation(\"writable root /Users/<user>/Documents/Codex contains symlink component /Users/<user>/Documents; symlinked writable roots are not supported\")" }

The same failure kills the node_repl MCP kernel on start:

Error: writable root /Users/<user>/Documents/Codex contains symlink component /Users/<user>/Documents; symlinked writable roots are not supported

The check is normalize_writable_root_for_sandbox in codex-rs/sandboxing/src/seatbelt.rs. Its only opt-out, allow_symlinked_codex_home = true, applies to roots under CODEX_HOME, so no configuration makes the default projectless location usable, and the app exposes no setting for that location.

This affects every user on a OneDrive-redirected Mac (a very common enterprise configuration), on their very first chat, before they know what a Project is.

What steps can reproduce the bug?

1. macOS with OneDrive Known Folder Move enabled (~/Documents is a symlink into ~/Library/CloudStorage/...).
2. Open the ChatGPT desktop app and start a Codex chat without attaching a project.
3. Ask it to run any shell command, or invoke a skill that runs a script.

What is the expected behavior?

Any of:

1. Canonicalize the projectless workspace root (resolve ~/Documents to its real path) before Seatbelt preparation; the app already stores canonical paths for project trust entries.
2. An opt-in equivalent to allow_symlinked_codex_home for workspace roots (e.g. allow_symlinked_workspace_roots), or tolerance for symlink components whose target is under the user's home.
3. A configurable default location for projectless chats (or not defaulting to ~/Documents at all, see App silently creates empty ~/Documents/Codex folder on every launch #20880), so enterprises can point it at a non-synced folder.

Additional information

Related

• macOS desktop upgrade can strand existing local tasks on stale symlinked writable roots #40121 — same error string on macOS with cloud-synced symlinked roots (Dropbox), stale-root angle
• Symlinked .codex breaks the entire macOS sandbox in rust-v0.149.0 #39874 — symlinked ~/.codex broke the sandbox after the symlink check landed (led to allow_symlinked_codex_home)
• Codex Desktop should avoid OneDrive-backed Documents as the default Windows project location #22532, Windows Desktop ignores redirected Documents Known Folder for projectless workspaces #33515 — Windows: OneDrive-backed Documents as the default projectless location
• App silently creates empty ~/Documents/Codex folder on every launch #20880 — app creates ~/Documents/Codex on every launch
• apply_patch fails when writable roots are symlinked (bwrap bind error) #14694 — Linux bwrap equivalent, fixed