Codex App ignores redirected Windows Documents Known Folder for projectless workspaces

What version of the Codex App are you using (From “About Codex” dialog)?

26.721.11231.0 (Windows AppX package version)

What subscription do you have?

Unknown / not exposed in the task environment used to reproduce this issue.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, a projectless Codex task may be created under
C:\Users\<user>\Documents\Codex\... even when the Windows Documents Known
Folder has been redirected to D:\Users\<user>\Documents.

The system configuration was verified from PowerShell:

[Environment]::GetFolderPath('MyDocuments')
# D:\Users\<user>\Documents

(Get-ItemProperty `
  'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders'
).Personal
# D:\Users\<user>\Documents

The legacy C: path is only a directory junction:

Path       : C:\Users\<user>\Documents
LinkType   : Junction
Target     : D:\Users\<user>\Documents

Despite that, the projectless task initially received this current workspace:

C:\Users\<user>\Documents\Codex\2026-07-30\new-chat-3

Later in the same task, the environment exposed the D: path directly. This
creates inconsistent workspace-root and sandbox-permission paths within one
task. It also means the app depends on the compatibility junction remaining
present. Removing the junction could make an existing task inaccessible even
though the actual Documents folder still exists at the configured Known Folder
location.

This behavior suggests the app may be constructing
%USERPROFILE%\Documents instead of consistently resolving
FOLDERID_Documents (or the equivalent Windows Known Folder API).

What steps can reproduce the bug?

1. On Windows, move the user's Documents Known Folder to another drive through

the supported Windows folder-location UI, for example:
D:\Users\<user>\Documents.

1. Verify that [Environment]::GetFolderPath('MyDocuments') returns the D:

path and that User Shell Folders\Personal has the same value.

1. Leave the compatibility junction at

C:\Users\<user>\Documents -> D:\Users\<user>\Documents.

1. Start a new projectless task in the Codex App.
2. Inspect the task current working directory and writable workspace roots.
3. Observe that Codex may use

C:\Users\<user>\Documents\Codex\... rather than the configured D: Known
Folder path. In this reproduction, the exposed path later changed to D:
within the same task.

What is the expected behavior?

Codex App should resolve the Windows Documents Known Folder through
FOLDERID_Documents (or an equivalent supported API) and consistently use the
returned canonical path for projectless task creation, current working
directories, output locations, and sandbox roots.

For this configuration, new projectless tasks should be created directly under:

D:\Users\<user>\Documents\Codex\...

The task should not depend on
C:\Users\<user>\Documents existing as a junction, and the exposed workspace
path should not switch between C: and D: aliases during the task.

Additional information

Related but distinct issues:

• #20880 concerns creating ~/Documents/Codex automatically.
• #22532 concerns avoiding OneDrive-backed Documents.

This report specifically concerns honoring a non-OneDrive Windows Known Folder
redirection and keeping the projectless workspace path canonical and stable.