Codex App: add default parent folder setting for Start from scratch projects

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

• #19909

Powered by Codex Action

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.

Please fix this, its a nightmare that that is the first think I am searching in the app and its HARDCODED??? Really???

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

This is even more useful because without #11022 being fixed, moving them later is near-impossible.

I also cannot use "Start from scratch" feature because projects are created not where I keep all my projects, so I have to create folders manually first and use "Use existing folder".

This issue happened to me as well. I'd love to fix it if codex team allows me to (i.e. PRs are invite-only).

The lack of a configurable default parent directory is extremely user-hostile. Users have different repository layouts, volumes, backup policies, security requirements, and iCloud configurations; forcing new work into a hardcoded ~/Documents/Codex hierarchy is not an acceptable default without an override.

The situation is even more frustrating because Codex explicitly verifies that the projectless root is not a symbolic link. That means users cannot configure the directory in Settings or config.toml, and they are also prevented from using the normal Unix workaround to redirect it themselves. A hardcoded path plus deliberate symlink rejection leaves users with no clean escape route.

Please add a supported default-parent/projectless-workspace setting and persist it. At an absolute minimum, resolve symlinks and validate the real target instead of rejecting them outright. The current behavior disregards user ownership of the filesystem.

I can reproduce the same underlying behavior on Codex Desktop for Windows.

Environment:

• Codex Desktop package: 26.715.3651.0
• Windows 11
• Current result: creating a new local project from the Projects UI creates it directly under the Windows Documents known folder, for example C:\Users\<user>\Documents\<Project Name>.
• Desired parent in this workflow: C:\Users\<user>\Documents\Codex, but ideally the parent should be user-selectable.

A minimal implementation could be:

1. Add Settings → General → Projects → Default project folder with a native directory picker and a reset-to-default action.
2. Persist the selected absolute parent directory as a Desktop-owned setting.
3. Apply it only to newly created local projects / “Start from scratch”. Keep existing projects and projectless thread workspaces unchanged.
4. Preserve the current OS Documents folder as the default when no custom parent is configured.
5. If the configured directory is missing or not writable, show an actionable error and let the user reselect/reset it rather than silently creating the project elsewhere.
6. Reuse the existing unique-name behavior for same-named folders.

Local inspection of the shipped Desktop bundle indicates that the current creation path is selected in the Electron-side createDefaultWorkspaceRoot flow using the OS Documents path, while the creation dialog only asks for the project name. I could not find that Desktop-specific implementation or its persisted workspace-state keys in the public openai/codex source tree, so a Rust-only public-repo change would not appear sufficient.

I would be willing to implement and test this as a focused external contribution. Since the repository contribution policy is invitation-only, could a maintainer clarify:

• whether an external PR would be welcome for this issue;
• which repository/source tree owns the Desktop project-creation flow; and
• whether the preferred persistence surface is a Desktop setting or a documented config.toml key?

If invited, I would keep the change limited to the setting, validation/fallback behavior, project-creation path selection, and focused cross-platform tests.