Windows Desktop: mapped SMB/NAS project history disappears after cwd is canonicalized to \\?\UNC

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

26.608.1337.0 Codex CLI: 0.138.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After a recent Codex Desktop update, project conversation history for workspaces on a mapped SMB/NAS drive disappeared from the Desktop UI after restarting the app.

The conversations were not deleted. The rollout JSONL files still existed and still contained the original mapped-drive cwd, but the local Desktop state database had affected threads.cwd values rewritten from the mapped-drive form to an extended UNC form:

<drive-letter>:\...
\\?\UNC\<server>\<share>\...

This made the Desktop sidebar/history treat the same workspace as a different project identity, so existing chats no longer appeared under the expected project.

I also found a second state issue: some valid user threads had non-empty first_user_message / rollout user turns, but threads.has_user_event was stale or false. Those threads could be filtered as if they had no user message.

Temporary local workaround used:

• backed up the local Codex state database first
• normalized affected threads.cwd values back from \\?\UNC\... to the mapped-drive form
• set has_user_event = 1 for valid non-archived user threads with first_user_message or user turns
• kept subagent/guardian helper threads hidden
• added local SQLite triggers so future inserts/updates normalize the mapped SMB/NAS path and maintain the visibility flag

After this local repair, the missing mapped-drive project history became visible again in Codex Desktop.

What steps can reproduce the bug?

1. On Windows, use Codex Desktop with a project stored on a NAS share mounted as a mapped SMB/CIFS drive.
2. Create or use multiple conversations in that mapped-drive project.
3. Close and reopen Codex Desktop, especially after an app update or local history/state migration.
4. Observe that the project sidebar/history no longer shows the expected conversations.
5. Inspect the original rollout JSONL files:

• session_meta.cwd
• turn_context.cwd

These still contain the mapped-drive path.

1. Inspect the local Desktop state database:

• threads.cwd may contain \\?\UNC\<server>\<share>\...
• some valid user threads may have stale has_user_event = 0 despite having first_user_message or rollout user turns

1. Normalize threads.cwd back to the mapped-drive form and repair stale user-thread visibility metadata.
2. The missing project conversations become visible again.

What is the expected behavior?

Codex Desktop should not make local project history appear lost because of Windows path canonicalization.

Equivalent Windows paths should be treated as the same workspace identity when grouping, searching, resuming, and displaying history:

<drive-letter>:\...
\\server\share\...
\\?\UNC\server\share\...

Desktop history visibility should also be based on durable rollout metadata or consistently maintained thread metadata. A valid user conversation should not be hidden just because a denormalized field such as has_user_event is stale while first_user_message and rollout user turns exist.

For SMB/NAS workspaces, please also clarify the intended Windows sandbox behavior:

1. Are mapped SMB/CIFS drives expected to work inside the Windows filesystem sandbox?
2. Should sandbox allowlists match the mapped-drive path, UNC path, or both?
3. Are \\?\UNC\..., \\server\share\..., and mapped drive paths normalized before sandbox checks?
4. If SMB/NAS workspaces are not currently supported, is support planned?
5. What is the recommended safe configuration for users whose main projects live on NAS storage?

Additional information

_No response_