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

Codex should not silently create ~/Documents/Codex on launch.

Every time I open the Codex app, an empty ~/Documents/Codex folder appears in my Documents directory. It stays empty after I close the app, and I have to delete it by hand. This happens whether or not I start a project.

~/Documents is the user's space. macOS-native apps do not write into it without explicit user action, and a well-behaved app from any platform should follow the same convention. Silently creating a folder there on every launch is the kind of behavior users associate with sloppy Windows-era installers, and it is out of place in a modern Mac app.

Please change this. Acceptable options, in order of preference:

Don't create the folder at all until the user explicitly starts a project that needs disk output. If a project is never started, no folder should ever appear.
Ask the user once, on first launch or first project, where projects should live, and remember that choice (this also resolves Codex App: add default parent folder setting for Start from scratch projects #19913 and Feature Request: [App] Make the "Chats" project directory configurable #19909).
Use a hidden application-support location (~/Library/Application Support/Codex/ or ~/.codex/) for any internal scaffolding the app needs, and only touch ~/Documents when the user saves something there.

"Codex needs a working directory" is not a justification for putting it in ~/Documents without asking. If the directory is required, the app can create it under Application Support; ~/Documents is for the user's files, not the app's bookkeeping.

Environment

Codex App on macOS (Darwin 25.5.0)
Reproduces 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:

Do not create Documents/Codex on app launch.
Lazily create a projectless workspace only when a projectless chat actually needs local files.
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
If the app wants user-visible project folders, ask once and persist the parent directory.
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:

App silently creates empty ~/Documents/Codex folder on every launch #20880 — App silently creates empty ~/Documents/Codex folder on every launch.
Codex insists on opening sandbox projects on c: creating Documents under %USERPROFILE% when My documents is pointed to another location/drive #25198 — Windows creates C:\Users\<user>\Documents\Codex even when the Windows Documents known folder points to another drive.
Feature Request: [App] Make the "Chats" project directory configurable #19909 — Make the "Chats" project directory configurable.
Codex App: allow configuring default directory for projectless thread workspaces #22875 — Allow configuring default directory for projectless thread workspaces.
Support custom storage path for Codex Desktop Chats/projectless workspaces #24534 — Support custom storage path for Codex Desktop Chats/projectless workspaces.
Feature request: make default working directory for non-project conversations configurable #24734 — Make default working directory for non-project conversations configurable.
Codex Desktop: allow users to configure the default projectless workspace root #24883 — Allow users to configure the default projectless workspace root.
Codex Desktop: configurable default root for new project ideas and fast iterations #24632 — Configurable default root for new project ideas / fast iterations.
Codex App: add default parent folder setting for Start from scratch projects #19913 — Add default parent folder setting for Start from scratch projects.
Codex Desktop: allow configuring the default folder for new projects #25386 — Allow configuring the default folder for new projects.
Codex Desktop should avoid OneDrive-backed Documents as the default Windows project location #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:

Clarify new-thread context and support moving threads between General and Projects #24222 — Clarify new-thread context and support moving threads between General and Projects.
Cmd+N new chat should support a fixed default workspace instead of reusing the last/current project #25496 — Cmd+N new chat should support a fixed default workspace instead of reusing the last/current project.
Add “General Chat” mode + convert chat to project #12397 — Add General Chat mode + convert chat to project.
Allow Chats to be moved into, out of, and between Projects #22345 — Allow Chats to be moved into, out of, and between Projects.
Codex Desktop sidebar sort by recent: show project and execution-context metadata in the global recent chat list #24083 — Show project and execution-context metadata in the global recent chat list.
Add ability to update/migrate thread references when projects are moved to new locations #11022 — Update/migrate thread references when projects are moved.
Codex App reconnect loop when stale deleted workspace path is still referenced (ENOENT in git-origins) #13988 — Reconnect loop when a stale deleted workspace path is still referenced.
Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540, threads / projects in sidebar missing #18640, Windows Desktop: sidebar/project list lost after update; search still finds threads; projectless-thread-ids workaround restores flat chats but project grouping remains broken #19873, Codex Desktop bug report: recent conversation history hidden/stale despite local DB containing threads #21076, Desktop sidebar/search hides older local project chats although thread data still exists on disk (multi-project, reproducible) #21581, Codex Desktop 26.519.22136: local project conversation history missing after update, threads still exist in state_5.sqlite #23979, Codex macOS app project sidebar can hide existing local project chats after restart/cache drift while SQLite thread records remain intact #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:

App bookkeeping, projectless chats, generated workspaces, and user projects are not cleanly separated.
The default storage location is hardcoded/implicit instead of platform-correct and configurable.
Existing threads store path-derived identity, but users do not have supported tools to move, re-home, or repair that identity.
On macOS this collides with iCloud-backed ~/Documents.
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?

Huge fan of Codex using my finite iCloud quota as its personal dumping ground! Having my entire local dev environment forced into ~/Documents is truly a masterclass in cloud sync optimization.

Who needs a basic 'Custom Save Path' setting when you can experience the sheer adrenaline of watching 15,000 node_modules sync over Wi-Fi in real-time? If picking a target folder is still a stretch goal for the roadmap, let me know—Cursor and Claude Code wouldn't be a bad option.

Currently I've to add .nosyncextension to the Codex folder (Codex.nosync) to stop it from syncing.

I recently tried the new real-time voice feature in the latest ChatGPT Codex, but I’m starting to experience this issue. All voice chats are now silently saved in the ~/Documents/Codex directory.

I cannot even use the Voice mode since they are blocking my symlink 🫠

I believe it’s mostly resolved now. You can click on the “Add folders ChatGPT can read and edit” container and choose the preferred location and it’ll create the project at that location. However, the core issue persists; it still silently adds the Codex folder on every launch.

Perhaps this should be filed as a separate issue, I am not sure.

My Documents folder is under Ransomware protection (Controlled folder access is On in Virus & threat protection). Because of this, I am receiving a lot of notifications from Windows Security:
~~
Protected folder access blocked
App or process blocked: codex-windows-sandbox-setup.exe
Protected folder: %userprofile%\Documents
~~
Most often, the culprit is the sandbox setup process, but sometimes it can also be ChatGPT.exe. I reckon they are trying to create a Codex subfolder.

No way am I granting Codex write access to my Documents. The path to its working files should simply be configurable.

I can reproduce a related Linux variant.

Environment:

Ubuntu 24.04.4 LTS
ChatGPT/Codex app 26.810.41047
codex-desktop package 2026.08.14.025905
Locale: it_IT.UTF-8

The configured XDG Documents directory is localized:

$ xdg-user-dir DOCUMENTS
/home/marco/Documenti

(actually, that is just a symlink pointing to /media/dati/Documenti)

However, for projectless tasks the app selects a working directory under:

/home/marco/Documents/Codex/YYYY-MM-DD/

This indicates that ~/Documents is hardcoded instead of resolving
XDG_DOCUMENTS_DIR.

I currently use another symlink as a workaround:

/home/marco/Documents -> /media/dati/Documenti

Expected behavior:

For user-visible task output, honor XDG_DOCUMENTS_DIR or provide a
configurable default parent directory.
For internal scaffolding, use an appropriate XDG application-data location
and do not create anything under the user's Documents directory.

The empty ~/Documents/Codex folder is created on launch even when you never start a project. Deleting it every time does not stick.

Method:

Use Settings -> Add folders ChatGPT can read and edit, and point new projects at a folder you actually want.
On Linux, if Documents is localized (xdg-user-dir DOCUMENTS), add a ~/Documents -> symlink to that real folder so projectless tasks do not land in a second English path.
On Windows with Controlled folder access, do not grant Documents write just to silence the toast. Expect codex-windows-sandbox-setup.exe / ChatGPT.exe to keep trying that path until it is configurable.
Treat the leftover empty folder as launch scaffolding, not project data.

Evidence: the Add-folders UI lets you choose a project root, but the empty Codex folder still appears every launch. Linux reports show ~/Documents hardcoded instead of XDG_DOCUMENTS_DIR.

Independent community workaround; not an official OpenAI fix.

Navigation Menu

Repository navigation

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

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Environment

Activity

nos1609 commented on May 20, 2026

Delacrowa commented on May 21, 2026

DrWaKu commented on May 21, 2026

yoyo837 commented on May 27, 2026

nos1609 commented on Jun 2, 2026

yeliex commented on Jun 4, 2026

iLLHunter commented on Jun 4, 2026

iLLHunter commented on Jun 4, 2026

BobbySweaters commented on Jun 7, 2026

DanDanTheManDan commented on Jul 2, 2026

iLLHunter commented on Jul 3, 2026

alex-dunstan commented on Jul 10, 2026

pvieito commented on Jul 11, 2026

druchtx commented on Jul 12, 2026

Xesyliad commented on Jul 14, 2026

iLLHunter commented on Jul 14, 2026

chuzhe-as-a-dev commented on Jul 16, 2026

iaashu98 commented on Jul 22, 2026

p-jiang commented on Jul 24, 2026

pvieito commented on Jul 24, 2026

iaashu98 commented on Jul 29, 2026

vlpast commented on Aug 11, 2026

marco170475 commented on Aug 14, 2026

naipi11 commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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