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

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 #20880), so enterprises can point it at a non-synced folder.

Additional information

Related

• #40121 — same error string on macOS with cloud-synced symlinked roots (Dropbox), stale-root angle
• #39874 — symlinked ~/.codex broke the sandbox after the symlink check landed (led to allow_symlinked_codex_home)
• #22532, #33515 — Windows: OneDrive-backed Documents as the default projectless location
• #20880 — app creates ~/Documents/Codex on every launch
• #14694 — Linux bwrap equivalent, fixed

Start in codex-rs/sandboxing/src/seatbelt.rs at normalize_writable_root_for_sandbox, then inspect the projectless-root values in ~/.codex/.codex-global-state.json. Compare this path flow with the existing allow_symlinked_codex_home behavior. Done means projectless macOS chats can run commands and start node_repl when ~/Documents is a symlink, with coverage in the relevant sandbox tests.