›_ Codex Issues
Codex Issues / #32039

Codex Desktop blocks projectless chat creation when default workspace path is a valid symlink

Open 💬 4 comments Opened Jul 10, 2026 by johnsilvavlogs

Summary

Codex Desktop can no longer create a chat without selecting a project folder when the default projectless workspace path is a symlink to a real, writable directory.

The app rejects task creation with:

Error creating task
Projectless thread directory must be a real directory

Starting chats without folders is a core Codex Desktop workflow and was previously available. A valid filesystem indirection should not make the entire projectless-chat flow unavailable.

Environment

  • Codex Desktop: 26.707.31428 (build 5059)
  • macOS: 26.5.2 (build 25F84)
  • Architecture: Apple Silicon (arm64)
  • Default projectless path: ~/Documents/Codex
  • The path is a symlink to /Users/<user>/Codex
  • The symlink target exists, resolves as a directory, and is writable

Steps to reproduce

  1. Create a real writable directory outside ~/Documents:

``sh
mkdir -p ~/Codex
``

  1. Make the default projectless path point to it:

``sh
ln -s ~/Codex ~/Documents/Codex
``

  1. Open Codex Desktop.
  2. Start a new chat without selecting a project folder.
  3. Observe that task creation fails.

Actual behavior

The new task is not created. Codex shows:

Projectless thread directory must be a real directory

This makes chats without folders unavailable.

Expected behavior

Codex should create the projectless chat successfully when the configured/default path resolves to a real writable directory.

At minimum, Codex should resolve and validate the symlink target. Longer term, a supported configurable projectless workspace directory would avoid forcing users into the default ~/Documents/Codex path.

Why this is a bug rather than only a feature request

The immediate failure is not merely that the storage location is non-configurable. A previously supported user workflow—starting a chat without choosing a folder—is completely blocked even though the destination is a valid writable directory.

Related issues

  • #24534 tracks configurable storage for projectless workspaces.
  • #24734 reported the same error while requesting configuration support, but was closed as a duplicate.
  • This report isolates the current user-visible regression: valid projectless chat creation fails entirely.

Additional information

A screenshot of the error toast was captured and can be provided if needed.

View original on GitHub ↗

4 Comments

johnsilvavlogs · 1 month ago

Still reproducible in Codex Desktop 26.707.61608 (build 5200), and I isolated the failure to the Desktop app's projectless-root validation rather than SQLite, permissions, or the bundled app-server.

Additional evidence:

  • The default root was ~/Documents/Codex, a valid symlink whose target was an existing writable directory.
  • The packaged Desktop code hard-codes that path, inspects it without following symlinks, and rejects it when lstat reports isSymbolicLink(), producing the exact Projectless thread directory must be a real directory error before the workspace can be reserved.
  • I also downloaded and signature/Gatekeeper-verified the current signed appcast build 26.707.62119 (build 5211). Its packaged validator retains the same no-follow / isSymbolicLink() rejection, so updating alone would not change this behavior.
  • Local counterfactual: I replaced only ~/Documents/Codex and the current-date child with real local directories, while keeping compatibility links for the existing canonical workspaces. I did not restart/reinstall Codex, change the projectless preference, or reset the state database.
  • Immediately afterward, projectless creation succeeded twice: first through the projectless thread API (with a real generated work/ + outputs/ layout), then through the real Desktop UI using New task -> Don't work in a project. The UI-created thread persisted under ~/Documents/Codex/<date>/..., returned the expected canary response, and no new occurrence of the validation error appeared in the Desktop log.
  • PRAGMA integrity_check on the thread state DB is ok.

This confirms the causal chain:

projectless submit -> hard-coded ~/Documents/Codex -> lstat/no-follow validation -> symlink rejected -> workspace reservation aborts -> task creation fails

Suggested fix: resolve and validate the symlink target (including writable-directory and containment/safety checks), or make the projectless root officially configurable. If symlinks are intentionally unsupported, the app should provide an actionable migration instead of disabling the projectless workflow.

Earlier matching reports: #19909 (same error in April) and #24734 (same symlink rejection, closed as duplicate).

okker24 · 1 month ago

Confirmed on Windows as well, using an NTFS junction rather than a macOS symlink.

Environment

  • Codex Desktop package: 26.707.9981.0
  • OS: Windows (x64)
  • Default projectless path: C:\Users\<user>\Documents\Codex
  • That path is an existing directory junction (Directory, ReparsePoint) whose target is an existing local directory.

Reproduction

  1. Open a ChatGPT conversation in Codex Desktop and use the "Start task?" handoff card.
  2. Click "Continue task" (or focus it and press Enter).
  3. The button accepts the input and shows a spinner, but the task never opens.

The desktop process remains responsive. The app log records the same failure twice, once per attempt:

Failed to create Codex thread from ChatGPT conversation
errorMessage="Projectless thread directory must be a real directory"

No error toast or actionable message is shown in this handoff flow; the UI only keeps spinning. So there are two user-visible problems on Windows:

  1. A valid NTFS directory junction is rejected as not being a real directory.
  2. The ChatGPT-to-Codex handoff UI does not surface the failure or recover the button state.

This is reproducible with both mouse click and Enter, confirming it is not an input/focus issue. Resolving and validating the junction target should address the root failure; the handoff UI should also stop the spinner and show the underlying error.

Ccyuan233 · 12 days ago

I can reproduce this issue on the current Windows version using an NTFS directory junction.

Environment

  • Codex Desktop/MSIX: 26.810.7004.0
  • OS: Windows 11 Home, 10.0.26200, x64
  • CODEX_HOME: E:\Codex\state
  • Default projectless path: C:\Users\<user>\Documents\Codex
  • Junction target: E:\Codex\projects

PowerShell reports:

Get-Item 'C:\Users\<user>\Documents\Codex' |
    Format-List FullName, LinkType, Target
FullName : C:\Users\<user>\Documents\Codex
LinkType : Junction
Target   : E:\Codex\projects

Both the junction and its target exist, resolve to directories, and are writable. However, creating a projectless Work chat fails with:

Projectless thread directory must be a real directory

Opening an actual project folder on E:\ works correctly. Only the projectless-chat workflow is blocked.

The packaged Windows app appears to construct the projectless root as:

<home directory>\Documents\Codex

and then reject it when filesystem metadata reports that it is a symlink/junction. Therefore, moving CODEX_HOME does not provide a way to relocate projectless workspace files.

Expected behavior

Codex should either:

  1. Resolve the junction and validate/sandbox the canonical target directory; or
  2. Provide a supported setting for the projectless workspace root.

This is especially important on Windows systems where users keep development files on another drive due to storage, backup, or performance requirements.

adamlove86 · 3 days ago

Confirmed on the current Windows build, with an additional ChatGPT Chrome side-panel impact.

Environment

  • Codex Desktop/MSIX: 26.818.8289.0 (x64)
  • Windows 11 Home: 10.0.26200 (x64)
  • Chrome: 151.0.7922.172
  • Default projectless path: C:\Users\<user>\Documents\Codex
  • Junction target: E:\MovedUserData\CodexWorkspaces\Documents_Codex

The source path is an existing NTFS directory junction (Directory, ReparsePoint). Its target exists, is a real directory, and is writable.

Chrome side-panel reproduction

  1. Open the ChatGPT extension side panel in Chrome.
  2. Enter any prompt in the side chat.
  3. Submit it.
  4. Chat creation fails immediately with:
Error creating chat
Projectless thread directory must be a real directory

The side panel itself loads, so this is not a missing-extension/native-host connection failure. The failure occurs when the panel tries to create its projectless ChatGPT/Work thread. In practice this makes the entire Chrome side chat unusable, not just a Codex Desktop "new task" entry point.

Local cause confirmed in the packaged app

The packaged app.asar for 26.818.8289.0 still:

  1. Constructs the root as path.join(homeDirectory, "Documents", "Codex").
  2. Reads metadata without following links/reparse points.
  3. Rejects the path when metadata reports isSymlink.

That causal path matches the visible failure exactly:

Chrome side chat submit
→ projectless thread creation
→ hard-coded Documents\Codex root
→ junction rejected without resolving target
→ chat creation aborts

Expected

Resolve and validate the canonical junction target (directory + writability + containment checks), or provide a supported configurable projectless workspace root. A valid junction should not disable projectless chats or the ChatGPT Chrome side panel.

A screenshot showing the full Chrome panel and error toast is available if maintainers need it.