App silently creates empty `~/Documents/Codex` folder on every launch

Same behavior on Windows, codex creates C:\Users\nos1609\Documents\Codex ignoring the system path from Windows registry pointing that the Documents directory is actually at a different location and even a different drive.

Looks like same mechanics as used in Linux's xdg-user-dirs have to be implemented on every OS prior to create any custom directory without user's consent.

I can reproduce this as well.

Codex Desktop creates an empty ~/Documents/Codex folder on every launch, even when I do not start or save any project. Deleting the folder does not help because it is recreated the next time the app opens.

Expected behavior:
Codex should not create anything in ~/Documents without explicit user action, or it should let the user choose the default project location.

Environment:

• OS: macOS 26.4.1, 26.5.0
• Codex app version: 26.513.31313 (2867)

Worth zooming out, because this isn't really a Codex-specific bug, it's a pattern that a lot of Mac users have been quietly annoyed by for years.

There's a long tradition of cross-platform apps with a Windows or web-server center of gravity (Adobe, Zoom, Cisco, lots of Electron-based tools) treating ~/Documents/<BrandName> as a default home whether the app needs a user-visible folder or not. The same culture tends to plant login items and background helpers on install. After six months on a fresh Mac you have a Documents folder full of vendor-branded directories you never asked for, half of them empty, and a login items list that reads like a trade show floor. It's the kind of behavior that made Windows machines feel slow and cluttered by month three, and it's frustrating to see it migrate over to macOS one Electron app at a time.

macOS has had a different convention for a long time: internal scaffolding belongs in ~/Library/Application Support/<bundle-id>/, and ~/Documents is the user's space. Sandboxed apps literally cannot write to ~/Documents without entitlement and consent. There's even a community term of art for apps that respect this: a \"Mac-assed Mac app\", one that follows the HIG, stores its internals where they belong, and treats the user's folders as the user's. Panic, Omni Group, Bare Bones, Rogue Amoeba, and newer dev tools like Linear, Raycast, and Ghostty all clear that bar without anyone having to file an issue about it.

My read on what's happening with Codex App: this isn't a branding move, it's the framework default. Electron and similar toolchains hand you \os.homedir()\ + a hardcoded folder name, and if nobody on the team owns \"macOS platform fit\", that default ships. It's lazy engineering more than anything malicious, which is almost worse, because it means nobody on the desktop side thought the question was worth asking. The Windows report in this thread (ignoring the registry's actual Documents path and hardcoding \C:\Users\<name>\Documents\Codex\) is the same disease on a different OS: the app assumes one path layout everywhere instead of asking the system.

The fix is cheap and well-trodden:

• Default internal state to \~/Library/Application Support/Codex/\ on macOS, \%LOCALAPPDATA%\ on Windows, \\$XDG_DATA_HOME\ on Linux.
• Ask once, on first project creation, where user-visible projects should live, and remember it.
• Never create anything in \~/Documents\ until the user explicitly saves something there.

That also closes #19909 (iCloud-synced Documents is hostile to chat/code storage) and #19913 (configurable project parent) as side effects.

For a tool aimed squarely at developers, \"respect the platform you ship on\" should be table stakes.

I am also experiencing this on macOS (Darwin). Codex creates ~/Documents/Codex which conflicts with iCloud sync — I had to move the directory to ~/.codex-workspace and symlink it back. Would love a configurable default workspace path or at minimum using ~/Library/Application Support/Codex/ as the default instead. Also related: #19909 #19913.

Adding concrete Windows evidence from a local Codex Desktop install, because this is not just a macOS convention issue.

Environment:

• Windows
• Codex Desktop package: OpenAI.Codex_26.527.7698.0_x64
• Windows Known Folder Documents is relocated to another drive:
• [Environment]::GetFolderPath("MyDocuments") returns D:\...\Documents
• $env:USERPROFILE is C:\Users\...

Observed behavior:

Codex still creates projectless workspaces under:

C:\Users\<user>\Documents\Codex\YYYY-MM-DD\<thread-slug>\
C:\Users\<user>\Documents\Codex\YYYY-MM-DD\<thread-slug>\work\
C:\Users\<user>\Documents\Codex\YYYY-MM-DD\<thread-slug>\outputs\

So on Windows this is worse than "uses Documents by default": it ignores the OS-configured Documents location and hardcodes a synthetic path under %USERPROFILE%\Documents.

I inspected the installed Desktop bundle. The relevant projectless path builder is desktop-side, not app-server-side:

path.join(homeDirectory, "Documents", "Codex")

and the host passes:

homeDirectory: os.homedir()

to the projectless-thread-cwd / projectless-workspace-root handlers.

The projectless directory creation then does roughly:

createDirectory(workspaceRoot, { recursive: true })
createDirectory(dateDir, { recursive: true })
createDirectory(threadDir)
createDirectory(outputs)
createDirectory(work)

This explains why Windows Known Folder redirection is ignored: os.homedir() gives C:\Users\<user>, and the app appends Documents\Codex manually instead of asking the platform where Documents or application data actually live.

I also checked the visible openai/codex source tree. The Rust app-server already accepts a caller-provided cwd in thread/start; it is not the component deciding that projectless workspaces belong in Documents. The Desktop host computes the projectless cwd before app-server sees it.

This also does not appear to be configurable through ~/.codex/config.toml. The config schema has path-ish settings such as log_dir and sandbox_workspace_write, but nothing like projectless_workspace_root, default_workspace_root, projectless_output_dir, or a "do not create projectless directories" option.

Suggested fix:

1. Do not create Documents/Codex on app launch.
2. Lazily create a projectless workspace only when a projectless chat actually needs local files.
3. Store internal projectless scaffolding in platform app-data, not user documents:

• macOS: ~/Library/Application Support/Codex/ or Electron app.getPath("userData")
• Windows: %LOCALAPPDATA%\OpenAI\Codex\... / Electron app.getPath("userData")
• Linux: $XDG_DATA_HOME/codex or ~/.local/share/codex

1. If the app wants user-visible project folders, ask once and persist the parent directory.
2. If Documents is used at all, use the OS-provided Known Folder / Electron app.getPath("documents"), not os.homedir() + "/Documents".

This issue should probably be treated as two bugs plus one missing setting:

• silent write into a user-visible folder without consent;
• incorrect platform path handling on Windows;
• no configurable projectless/default workspace parent.

The current behavior is especially painful on machines with a small system drive, redirected Documents, or cloud-synced Documents. It silently consumes space in the wrong place and makes projectless chats look like user files even though they are app bookkeeping.

Related issue cluster / evidence that this is not isolated:

Directly about Documents/Codex, projectless/chats storage, or default project folders:

• #20880 — App silently creates empty ~/Documents/Codex folder on every launch.
• #25198 — Windows creates C:\Users\<user>\Documents\Codex even when the Windows Documents known folder points to another drive.
• #19909 — Make the "Chats" project directory configurable.
• #22875 — Allow configuring default directory for projectless thread workspaces.
• #24534 — Support custom storage path for Codex Desktop Chats/projectless workspaces.
• #24734 — Make default working directory for non-project conversations configurable.
• #24883 — Allow users to configure the default projectless workspace root.
• #24632 — Configurable default root for new project ideas / fast iterations.
• #19913 — Add default parent folder setting for Start from scratch projects.
• #25386 — Allow configuring the default folder for new projects.
• #22532 — Avoid OneDrive-backed Documents as the default Windows project location.

Adjacent UX/state issues caused by the same underlying model problem: thread/workspace/project location is implicit, sticky, hard to inspect, and hard to change later:

• #24222 — Clarify new-thread context and support moving threads between General and Projects.
• #25496 — Cmd+N new chat should support a fixed default workspace instead of reusing the last/current project.
• #12397 — Add General Chat mode + convert chat to project.
• #22345 — Allow Chats to be moved into, out of, and between Projects.
• #24083 — Show project and execution-context metadata in the global recent chat list.
• #11022 — Update/migrate thread references when projects are moved.
• #13988 — Reconnect loop when a stale deleted workspace path is still referenced.
• #17540, #18640, #19873, #21076, #21581, #23979, #25574 — several variants of Desktop sidebar/history/project grouping drifting from the underlying local thread data.

So this is not one macOS paper-cut and not one Windows path bug. It is a broader Desktop product-model problem:

1. App bookkeeping, projectless chats, generated workspaces, and user projects are not cleanly separated.
2. The default storage location is hardcoded/implicit instead of platform-correct and configurable.
3. Existing threads store path-derived identity, but users do not have supported tools to move, re-home, or repair that identity.
4. On macOS this collides with iCloud-backed ~/Documents.
5. On Windows this collides with Known Folder redirection, OneDrive-backed Documents, small system drives, WSL/dev-drive workflows, and normal user expectations around %LOCALAPPDATA% vs user documents.

A proper fix should probably cover all of these at once:

• stop creating Documents/Codex on launch;
• use platform app-data for internal state;
• add a supported setting for projectless/chat workspace root;
• add a supported setting for new project parent folder;
• use OS APIs for known folders when a user-visible folder is actually intended;
• expose supported move/re-home/repair operations for existing chats and projects.

Maybe this whole bunch need some kind of rethink (proably $superpowers:brainstorming skill) but more with human-minded design approach if the app is still meant to be used by humans cause for now emails offering to try the Codex App looks a bit disappointing considering I spend more time using workarounds like soft links instead of enjoying anything app-related.

if sync ~/Document with icloud and run something through codex chat mode, it may sync entire node_modules into iCloud!

This is clearly an issue affecting multiple people's ability to work and use the program. I wonder how long this issue will sit before it gets fixed?

In my ticket I noticed Codex ignores the operating system. It creates %USERPROFILE%\Documents, in the c: drive where the profile lives under c:\Users even when Windows reports Documents is on the d: drive at say d:\documents. It is hard-coded to make this %USERPROFILE%\Documents. Just poor/lazy coding tbh.

Given this would be such an easy dev fix, and not being addressed, worth uninstalling the app TBH.

I don't understand why Codex does not allow the user specify a default project folder.

July 3rd. Issue opened May 3rd. Countless related issues and users affected. Still unresolved. Keep this in mind next time the renewal is up, we are paying to be ignored.

+1 launch behaviour still re-creates/uses that path across runs.

we all want one thing: the ability to set and move the workspace location.

Please add a clear path choice (in settings or on first run/project setup), and persist it.
No hidden defaulting to ~/Documents/Codex without user choice.

Let users simply choose workspace folder once, store it in preferences, allow change/update later.

This behavior is extremely user-hostile. ~/Documents is user-owned space and, on macOS, is very commonly synced through iCloud. Codex should not silently create and repeatedly recreate ~/Documents/Codex, especially when there is no supported setting to move projectless workspaces somewhere appropriate such as ~/Library/Application Support/Codex or a user-selected directory.

What makes this substantially worse is that Codex explicitly rejects symbolic links with Projectless thread directory must be a real directory. Users are therefore denied even the standard Unix escape hatch for working around a bad hardcoded path. Hardcoding the location, providing no configuration, and then deliberately blocking symlink-based redirection is an unusually hostile combination.

Please either make the projectless workspace root configurable, respect a symlink after resolving and validating its target, or stop putting internal workspace scaffolding in Documents. There is no reasonable justification for forcing this location.

I would really appreciate it if the default behavior of Codex creating a folder under my Documents directory could be reconsidered. I use this directory for my personal files synced via iCloud, and it would be incredibly helpful to have an option to set a custom path. I am really looking forward to seeing this issue resolved soon.

Codex should obtain the Documents folder location using the Windows Known Folder API (FOLDERID_Documents / SHGetKnownFolderPath) or another supported Windows API rather than constructing the path from %USERPROFILE%.

Additionally, providing a user-configurable setting for the projectless thread storage location would give users greater control and better align with common Windows workflows.

Still unassigned. Ignored. Codex could fix this bug in 4 minutes...

Seriously? How much slop does there have to be for this issue to remain unresolved to this day?