Codex App: allow configuring default directory for projectless thread workspaces

I can confirm this has a significant real-world impact when the macOS Documents directory is mirrored by a cloud-storage client.

Environment:

• Codex App 26.707.31428 (5059)
• macOS 26.4.1 (25E253), Apple Silicon
• Google Drive for desktop 127.0.1.0

A projectless Codex workspace under:

/Users/<user>/Documents/Codex/2026-06-06/<thread>/work/mui-x/

contained a large repository with node_modules. Because Google Drive was configured to mirror the standard Documents folder, DriveFS continuously attempted to checksum and upload those generated development artifacts.

The observed failure loop repeatedly produced errors such as:

Checksumming .../node_modules/<package> failed with FAILED_PRECONDITION:
Could not read 8388608 bytes from file ...: Is a directory

UploadRetryMergeQueueItem: attempts=20 ... PARTIAL_RESULTS

During the loop:

• Google Drive consumed approximately 190% CPU and 2 GB RAM.
• Its drive_fs.txt log reached approximately 128 MB and rotated every 2–3 minutes.
• Antivirus scanning of the same filesystem churn consumed approximately another full CPU core.
• Restarting Drive did not resolve the problem because it resumed the same upload retry queue.

This is not merely an organizational preference: Documents is commonly selected for iCloud Drive, Google Drive, OneDrive, backup, and enterprise redirection. Putting repositories, dependency trees, symlinks, build outputs, and temporary agent workspaces there can trigger large uploads, indexing, conflict handling, and retry loops without the user realizing that a projectless chat created them.

Suggested behavior:

1. Provide a supported UI/config option such as projectless_workspace_root.
2. Default projectless workspaces to an application-data/cache location such as ~/Library/Application Support/Codex/Workspaces or ~/.codex/workspaces, rather than ~/Documents.
3. During onboarding, clearly explain if the chosen directory may contain repositories, dependencies, and build artifacts.

Opening an existing project under ~/repos avoids the issue, but it does not address casual/projectless chats, which are precisely where users are least likely to anticipate a generated repository under a cloud-synced Documents folder.

I also traced the current public main implementation (4ba28150146e8ae8e949a07951639a929f5ddeae) to identify the smallest likely implementation seam.

The public app-server already accepts a client-selected working directory through ThreadStartParams.cwd:

https://github.com/openai/codex/blob/4ba28150146e8ae8e949a07951639a929f5ddeae/codex-rs/app-server-protocol/src/protocol/v2/thread.rs#L56-L75

It also already persists opaque Desktop-owned settings under the [desktop] config table:

https://github.com/openai/codex/blob/4ba28150146e8ae8e949a07951639a929f5ddeae/codex-rs/config/src/config_toml.rs#L496-L502

I could not find the Documents/Codex literal or the projectless workspace path-selection logic in the public repository. This suggests the path is selected by the Desktop client before it sends thread/start, rather than by the Rust app-server.

A minimal implementation therefore appears to be Desktop-owned:

1. Store a setting such as desktop.projectlessWorkspaceRoot using the existing opaque Desktop config map.
2. Add a directory picker under Desktop workspace settings.
3. When creating a projectless thread, generate the date/slug directory under that root and pass it as the existing thread/start.cwd value.
4. Keep existing thread paths unchanged; apply the setting only to newly created projectless threads.
5. Validate that the selected root is absolute, creatable, and still available. If it becomes unavailable, prompt the user rather than silently reverting to a cloud-synced Documents directory.
6. Test macOS and Windows path selection, removed/unmounted roots, permissions, and restart persistence.

This should not require a new app-server protocol field, and may not require any Rust change at all unless the team prefers a typed config key instead of the existing Desktop settings map.

I understand that external PRs are invitation-only. If there is a useful public-repository portion of this fix and this direction matches the intended architecture, I would be happy to prepare a focused invited PR. Otherwise, I hope this narrows the internal Desktop change enough to make it straightforward to pick up.

This default creates recurring cleanup work for me. Codex generates projectless workspaces under ~/Documents/Codex, although my actual projects live elsewhere. I repeatedly have to inspect and remove this tree manually, while moving or deleting it can break existing threads because they retain the original working directory.

This is a bad default for generated development artifacts. Users should be able to configure the workspace root, and Codex should default to an application-data or cache directory rather than Documents.

Please prioritize a supported projectless_workspace_root setting in the desktop UI or config.toml.

Adding to the chorus of this is a huge issue for corporate users. My company doesn't let me exclude any folders under Documents from OneDrive sync, so now OneDrive and related file operations are constantly pegging my CPU with "Uploading 10,000 files" - and for what it's worth, this was not an issue for me prior to the new ChatGPT Work/Codex app. Thanks for all you do, OpenAI team!

Adding a current macOS data point because the fixed path has a more serious side effect when Documents is synced by iCloud. This is still present in Codex Desktop 26.721.41059 on macOS 26.3.1.

I traced one write spike to a projectless workspace under ~/Documents/Codex. A dependency install created roughly 180k node_modules entries. Over that 14.5-hour boot, the SSD’s write counter increased by about 745 GB. macOS process counters reported about 503 GB from bird, fileproviderd, and cloudd, versus 3.5 GB from ChatGPT/Codex itself; resource reports also caught bird and fileproviderd each writing about 34 GB in under ten minutes. The Codex log database and WAL stayed unchanged, so this was not the separate SQLite logging bug.

I checked for a workaround: this build constructs the projectless root as ~/Documents/Codex, rejects a symlink there, and provides no setting to move it. This means normal high-file-count development work can be placed inside iCloud without the user choosing that, then heavily amplified by FileProvider metadata processing. Making the projectless workspace root configurable would address the problem; a non-iCloud default or warning would also help.

Still present on 26.820.60940 (macOS 15.7.9), same structure as reported: ~/Documents/Codex/<date>/<thread-slug>. Reported against 26.513 three months ago, so this isn't version-specific.

My use case is writing and document work rather than code, so most of what Codex generates lands in ~/Documents next to unrelated personal files.

Moving it out afterwards is the part that actually hurts: once a thread is bound to a generated path, moving the folder gives "Current working directory is missing" and there is no way to relink it. Re-adding the folder registers a new project and the chat history is gone.

So the default location isn't only clutter — per thread it's effectively permanent. A documented projectless_workspace_root key would be enough on its own; a UI setting isn't required.