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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #19798

Powered by Codex Action

not a dupe

Adding another data point from macOS/Codex Desktop.

The hardcoded projectless/chat directory at ~/Documents/Codex is a real problem when Desktop & Documents is backed by iCloud Drive. In that setup, every new "Start from scratch" chat creates local workspace files under an iCloud-managed area, which can trigger File Provider sync churn and puts transient agent work in cloud sync by default.

Workarounds are limited because Codex Desktop appears to require this exact location and rejects a symlink:

Error starting chat
Projectless thread directory must be a real directory

I tried moving the folder to ~/.codex/projectless-chats and symlinking ~/Documents/Codex back to it, but new chats fail with the error above. Updating local state/config paths also does not solve new projectless chat creation, because the Desktop app recreates/uses ~/Documents/Codex.

What would fix this cleanly:

• a Desktop setting for the default parent folder for projectless chats / "Start from scratch" workspaces;
• or a config key such as projectless_workspace_root = "/Users/<user>/.codex/projectless-chats";
• and symlink support would also make advanced local setups much easier.

Related: #19913 asks for the same default-parent-folder behavior from a slightly different angle.

Please fix this embarrassing oversight openai. What the hell is Sam Altman and friends doing releasing an application that forces data into a user's documents folder with no option to configure otherwise. I watched a video and got super stoked for the New Codex release but then spent 2 hours thinking I was insane because I couldn't configure where the default save location setting was for "project from scratch", come to find out you guys didn't even program in this most basic of all basic functionalities. Pathetic. Great first experience. Fucking pissed off and crashing out.

Same from a Windows perspective - a hardcoded %USERPROFILE%/Documents/Codex, which is especially egregious since that is _not_ necessarily even the location of the actual (movable) Documents folder and a place many users will never look.

Workaround - just starting all chats inside a "chats" project - is clumsy and provides simple chats with cluttered and irrelevant project context.

Personally I've already used ~/Documents/Codex as a workspace for Codex so chat features is unusable, as it will dump garbage there :(

Hello, I recently encountered the same issue, but my focus is not on creating this directory — rather, I want to understand why this directory can bypass TCC.

Since this appears to be some kind of special handling by Apple, I do not consider it a bug, abuse, or malware-like behavior. Therefore, instead of submitting an Issue, I created a Discussion for it. Here is the link: https://github.com/openai/codex/discussions/22247.

Additionally, I would also like to be able to define this directory myself. I usually create the /Volumes/TMP folder using the hdiutil together with diskutil.

My issue is related https://github.com/openai/codex/issues/22532#issuecomment-4450991985

Using Codex inside OneDrive mapped Documents is a nightmare because the .git objects never fully sync and the churn is endless. It’s surprising this wasn’t obvious from onset, Documents is the most synced by default folder on any modern OS. Curious as to how this design decision was made.

this is still an issues in the latest version. This makes using chats outside projects unusable, if it means it would save BS files into icloud Documents folder. Please fix.

Please allow us to either set this in the Codex app UI or the config.toml as a global variable.

Really need this feature, please, get it done

Really need this feature, please, get it done

@mambalong then please thumb it up. That's the metric the OAI team looks at.

Same problem as there https://github.com/openai/codex/issues/20880
looks like definitely an architectural design flaw, starting to annoying already on daily basis manually cleaning up those undesirables residues leftovers

Cosigned... so much is in C:\Users\user\.codex, why not by default put Chats there as well? Or at least allow users to select something else. Documents is where I store _my_ stuff, I don't like apps using a default dump.

Adding a quantified data point from a current macOS installation; this is still present in a newer release:

• Codex Desktop: 26.715.21425 (build 5488)
• macOS: 27.0 (arm64)
• Desktop & Documents is backed by iCloud Drive
• Current ~/Documents/Codex snapshot: 5.25 GiB, 43,786 files, 6,757 directories, and 425 symlinks
• 35,589 files in that tree were modified within the last three days
• Six Git repositories are present under generated chat directories

The Git metadata itself is not the main cost (about 32 MiB total). The larger problem is task-created dependency and build trees. One Codex-created site task alone installed a node_modules tree containing 29,604 files / 758 MiB inside ~/Documents/Codex.

Retained task records confirm that Codex executed four git clone operations into projectless-task work/ directories, while another task ran a site initializer that performs git init followed by npm ci. This means the impact is not just an unwanted empty folder: projectless tasks can turn an iCloud-backed Documents folder into an active package/build workspace and automatically create tens of thousands of transient sync items.

There is still no supported Desktop setting or documented config key for changing this root, and replacing ~/Documents/Codex with a symlink is rejected because the projectless root must be a real directory.

A good solution would be:

1. A Desktop setting and config key for projectless_workspace_root.
2. Separate configurable locations for temporary work and retained user-facing outputs.
3. An iCloud/OneDrive warning when the selected root is cloud-synced.
4. A storage panel or retention policy for old work/, dependency, virtual-environment, and build directories.
5. A backward-compatible migration flow that leaves existing task paths untouched unless the user explicitly migrates them.

All paths and project names in this report are intentionally anonymized.