Codex Desktop should avoid OneDrive-backed Documents as the default Windows project location

[MisterRound]

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.

[MisterRound]

Additional code-level finding from inspecting the installed Codex Desktop bundle:

The previous workaround of changing persisted workspace roots does not affect Projects -> Start from scratch. That flow has a separate main-process path.

In the packaged Desktop app (OpenAI.Codex_26.506.3741.0, app.asar), the relevant flow is:

pickOnboardingWorkspaceOrCreateDefault(...) {
  root = await this.pickLocalWorkspaceRoot();
  root ??= await this.createDefaultWorkspaceRoot(defaultProjectName);
  ...
}

async createDefaultWorkspaceRoot(projectName) {
  const name = this.sanitizeDefaultProjectName(projectName);
  const root = await this.findAvailableDefaultWorkspaceRoot(app.getPath("documents"), name, undefined);
  await mkdir(root, { recursive: true }, this.appServerClient);
  await this.initializeDefaultWorkspace(root); // git init
  ...
}

So the root cause is more specific than remembered workspace state: Start from scratch uses Electron app.getPath("documents") as the hardcoded parent folder for new local projects. On Windows systems where Documents is redirected by OneDrive Known Folder Move, app.getPath("documents") resolves into a OneDrive-backed path, so Codex creates New project, New project 2, etc. inside OneDrive.

Related open issues:

• Codex App: add default parent folder setting for Start from scratch projects #19913 requests a configurable default parent folder for Start from scratch projects.
• App silently creates empty ~/Documents/Codex folder on every launch #20880 reports the same underlying Documents-folder behavior on macOS, where the app creates ~/Documents/Codex.

Suggested implementation direction:

1. Add a supported setting/config key for the Start from scratch parent directory, rather than only relying on persisted workspace roots.
2. On Windows, detect when app.getPath("documents") resolves under OneDrive and warn or choose a safer local default.
3. In Windows + WSL mode, allow a WSL-native default parent such as /home/<linux-user>/..., displayed via \\wsl.localhost\... where the Windows UI needs it.

This means users cannot currently fix this through .codex-global-state.json workspace roots alone; the Start from scratch code path needs its own configurable parent directory or OneDrive avoidance logic.

[MisterRound]

Additional runtime evidence from Codex Desktop 26.506.3741.0 on Windows + WSL:

• The OneDrive default is not only a project-folder inconvenience. Codex stores and later consults project affinity in multiple user-state locations, including .codex-global-state.json, state_5.sqlite thread cwd, session JSONL metadata, ambient suggestions, config.toml project trust entries, and cap_sid cwd capability mappings.
• When the project root is C:\Users\<user>\OneDrive\Documents\New project, Desktop continues to launch WSL git probes against that root, for example git ls-files / git add -A with temp index state. In this environment that left OneDrive stuck in an incomplete upload state and created open handles under .git/objects.
• This also affects recovery: if OneDrive is stopped or broken, Codex may not load the expected project/chat history because the active project and transcript metadata still point at the OneDrive-backed project root.
• A manual migration required changing routing state to a WSL-native project root and patching old metadata carefully while avoiding live-open transcript files.

This makes the upstream fix more than a UX default: Desktop should avoid OneDrive-backed known folders for new projects, expose a configurable default project root, and ideally provide a supported project-state migration path from OneDrive to a local/WSL-native location.

[miraclebakelaser]

related: Feature Request: [App] Make the "Chats" project directory configurable #19909

[MisterRound]

Additional impact after migrating active work away from OneDrive/Documents.

The default-to-Documents behavior is especially harmful in Windows + WSL mode because it compounds two slow/fragile layers:

1. Documents is often redirected to OneDrive, causing sync churn on Codex-generated temp/cache/session files.
2. When the agent runs in WSL, any Windows-backed project/default root becomes /mnt/c/..., triggering the WSL cross-filesystem performance warning and slower IO.

In this setup the practical stable pattern is:

• active repos/projects under native WSL paths such as /home/<wsl-user>/<project>
• Windows/Codex home under C:\Users\<user>\.codex only for Desktop app state/config
• OneDrive paths treated as archive only, never active project/runtime state

A better new-project flow would let Windows Desktop users choose a persistent default root and, when WSL mode is enabled, strongly prefer a WSL-native default such as /home/<wsl-user> over Windows Documents/OneDrive.

[demonbane]

Ironically, I came here to file the exact opposite issue. I genuinely DO want my Codex projects in OneDrive, and on my machine they have been hardcoded to go into userprofile\Documents which is not where I want them. So I don't know if this is a simple default change or a deeper bug.

[MisterRound]

You're gonna be in a world of hurt if you move them into OneDrive unless you disable git, it's perpetual constant churn, I would batch copy backups to a OD folder but NOT keep it as a live project folder. Also Onedrive should be you default documents root, I'm surprised it's not mapped there? Either way I'd look at simply automating copying the actual project artifacts you want to backup to a OD destination instead of using it as a live folder. OD client is not made to handle the churn, you're talking about tens of thousands of git objects if not more for a typical project. Beyond that, your entire chat history will live there, which means if you turn off one drive or pause sync, your chat sessions will literally disappear if you launch it with OD paused or disabled. There's really no gain.

[demonbane]

Oh wow, I didn't realize that start from scratch actually puts your git repo inside that folder. That is absolutely terrible just as you described. I keep my git repos in a separate tree and just want the workspace metadata to be persisted in OneDrive really. (so I can switch to a different computer and keep working) But yes, for this specific issue, git repos absolutely should not be placed inside OneDrive.

[joshka]

This also has historically affected macOS with OneDrive. Unsure of whether it still does, but I'd never suggest doing git repos in OneDrive for that reason. The macOS setup uses ~/Documents as a OneDrive hooked up location too, so this should be avoided / configurable.