codex - 💡(How to fix) Fix Codex Desktop should avoid OneDrive-backed Documents as the default Windows project location [2 comments, 1 participants]

What version of Codex is running?

Codex Desktop on Windows. Exact Desktop build not included here because the issue is about the default workspace location behavior rather than a single runtime failure.

What platform is your computer?

Windows 11 with WSL2 enabled.

What issue are you seeing?

Codex Desktop can default or persist new/local project workspaces under the Windows Documents folder. On many Windows installs, Documents is redirected by OneDrive Known Folder Move, so the resulting workspace path becomes OneDrive-backed, for example:

C:\Users\<user>\OneDrive\Documents\<project>

This is a poor default for agent-driven coding work. Codex creates and modifies many files during normal operation, and Git repositories commonly keep frequently-open or lock-sensitive files under .git. OneDrive sync then becomes a source of persistent churn and fragility.

Why OneDrive-backed project folders are problematic

Observed/expected failure modes for Codex projects inside OneDrive-backed Documents:

• OneDrive may never reach a fully synced state while Git metadata and generated/temp files are open or changing.
• Git operations can become slow or flaky because the repository sits on a synced Windows filesystem.
• WSL-backed Codex sessions pay the additional /mnt/c filesystem performance cost, then add OneDrive sync overhead on top.
• If OneDrive is paused, stopped, unavailable, or mid-conflict, the project can appear broken even though the issue is the sync layer.
• The default encourages users into a location that is actively hostile to local development workflows.

This is especially rough for Windows Desktop + WSL users. The better local default is usually a non-synced development folder, and for WSL-backed sessions it is often a native WSL path such as:

/home/<linux-user>/<project>

or, from the Windows UI side:

\\wsl.localhost\Ubuntu\home\<linux-user>\<project>

What steps can reproduce the issue?

1. Use Codex Desktop on Windows where the user's Documents known folder is managed or redirected by OneDrive.
2. Create/open a local Codex project using the default project location or recently persisted workspace root.
3. Observe the workspace being placed or remembered under a OneDrive-backed Documents path.
4. Use the workspace for a Git repository or agent-driven coding session.
5. Observe OneDrive sync churn, open-file sync stalls, and poor Git/development ergonomics.

Expected behavior

Codex Desktop should avoid OneDrive-backed folders for new/default local project workspaces.

Possible fixes:

1. Detect when the proposed default folder is under OneDrive and warn before creating or selecting it.
2. Prefer a non-synced development default on Windows, such as %USERPROFILE%\source, %USERPROFILE%\Code, or another local app-selected folder.
3. For WSL-enabled sessions, offer a WSL-native default such as /home/<linux-user>/<project> and display it through the Windows UNC path when needed.
4. If a user explicitly chooses OneDrive anyway, allow it, but make it an intentional opt-in rather than the path of least resistance.

Actual behavior

Codex Desktop can persist and reopen a OneDrive-backed project root as the active/default workspace. Local state uses workspace-root fields equivalent to:

{
  "electron-saved-workspace-roots": ["C:\\Users\\<user>\\OneDrive\\Documents\\<project>"],
  "active-workspace-roots": ["C:\\Users\\<user>\\OneDrive\\Documents\\<project>"]
}

Additional context

This is not asking Codex to block OneDrive entirely. Some users may intentionally use synced folders. The issue is that OneDrive-backed Documents is a hazardous default for coding agents and Git workspaces, particularly on Windows + WSL setups where native WSL storage is materially better for development.