Windows Desktop ignores redirected Documents Known Folder for projectless workspaces

Summary

On a Windows installation where Documents is redirected by OneDrive Known Folder Move, Codex Desktop uses a path that does not even exist to store projectless threads, instead of resolving the effective Windows Known Folder.

Evidence

The Documents Known Folder registered by Windows resolves to:
C:\Users\<windows-user>\OneDrive\Documentos
That directory exists.

These paths do not exist on the system:
C:\Users\<windows-user>\Documents
C:\Users\<windows-user>\Documents\Codex

Even so, projectless threads were previously created under:
C:\Users\<windows-user>\Documents\Codex\<date>\<thread-slug>

I directly confirmed that this is hardcoded in the app: Codex textually constructs %USERPROFILE%\Documents\Codex instead of querying the effective Windows Known Folder (for example, via SHGetKnownFolderPath(FOLDERID_Documents) or an equivalent). I am not attaching the inspected code/binary snippet here; I can add further technical detail if useful.

Worth noting that on installations without OneDrive Known Folder Move active, the plain path C:\Users\<user>\Documents normally exists by Windows default — which is why this problem is only visible for users with that redirection active, as in my case.

There are two related but distinct problems:

1. The base directory for projectless threads is not configurable.
2. The Windows fallback ignores redirection, localization, and OneDrive Known Folder Move.

Expected behavior:

• For the Windows agent, correctly use the Known Folder when "Documents" is actually needed.
• For the WSL agent, allow choosing a native path, such as /home/<wsl-user>/workspace/codex.
• Do not silently create a parallel Documents tree that does not match the real Known Folder.
• Do not automatically move existing threads.

Related issues found before opening this one:

• #20880 — similar behavior reported on macOS, with a comment confirming the same pattern on Windows.
• #22532 — reports that the "Start from scratch" flow uses Electron's app.getPath("documents"), which correctly resolves to OneDrive; that is a different UX problem from this one, which is about the path not existing at all.
• #19909 / #19913 — feature requests to make the directory configurable.

I don't believe this issue is a duplicate of the ones above, since none of them specifically documents the case where the path used does not exist while the redirected Known Folder does exist and is not used.

Environment:

• Codex Desktop/MSIX: OpenAI.Codex 26.707.9981.0
• Windows 11, build 10.0.26200.8875, x64