Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on May 23, 2026
2. github-actions commented on May 23, 2026

   

   github-actionsbot

   on May 23, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Codex App sidebar hides many threads and some codex:// thread links fail to open existing local threads #23900
   • Codx Chat History Bug after updating #22971
   • Windows Desktop: cannot resume running thread due to C:\ path vs \\?\C:\ path mismatch #23803
   • Codex Desktop Windows - resume fails because same session path is compared in two Windows path formats. #23311
   • Codex Desktop 26.519.22136: local project conversation history missing after update, threads still exist in state_5.sqlite #23979

   Powered by Codex Action
3. jshaofa-ui commented on May 23, 2026

   

   jshaofa-ui

   on May 23, 2026

   More actions

   Solution: Codex #24178 — Conversations Empty + Stale Windows Path

   Issue: #24178
   Labels: bug, windows-os, app, session
   Competition: 1 comment (low competition)
   Estimated Value: $1,000–$3,000
   Created: 2026-05-23

   ---

   Problem Summary

   On Windows, Codex Desktop conversations become empty/unavailable over time. The underlying SQLite database and rollout JSONL files still exist, but the UI shows "No conversation." A related resume failure shows that Codex treats two equivalent Windows paths as different:

   cannot resume running thread 019e49af-... with stale path:
   requested `\\?\C:\Users\<USER>\.codex\sessions\...\rollout-....jsonl`,
   active `C:\Users\<USER>\.codex\sessions\...\rollout-....jsonl`
   

   These two paths refer to the same file on Windows, but Codex compares them as raw strings.

   Environment: Windows 11 Pro 26200, Codex 0.133.0.0, NTFS filesystem

   ---

   Root Cause Analysis

   Root Cause 1: Windows Path Normalization (Primary)

   Windows supports multiple equivalent path formats:

   Format	Example	Description
   Standard	C:\Users\foo\.codex\...	Standard Windows path
   UNC/Extended	\\?\C:\Users\foo\.codex\...	Extended-length path (32767 char limit)
   UNC Network	\\server\share\...	Network path
   Short name	C:\Users\FOO\APPD~1\...	8.3 short name

   The \\?\ prefix is automatically added by:

   1. Windows API functions when paths exceed 260 characters
   2. Node.js fs module when using certain operations
   3. Electron's native modules when resolving paths

   The bug: Codex stores paths in one format (e.g., C:\Users\...) but later resolves them in another format (e.g., \\?\C:\Users\...). The string comparison fails, causing:

   1. Resume failures ("stale path")
   2. Conversation lookup failures (path doesn't match database record)
   3. Session index desynchronization

   Root Cause 2: Session Index Desync (Secondary)

   The session_index.jsonl file appears to be incomplete or out of sync with the SQLite database. This could be caused by:

   1. Crash during index write: If the app crashes while writing to the index, the index becomes corrupted
   2. Concurrent writes: Multiple processes writing to the index without proper locking
   3. Path mismatch: The index stores paths in one format, but lookups use another format

   ---

   Proposed Fix

   Fix 1: Path Normalization Utility (Primary)

   // src/common/path-normalizer.ts
   
   import path from 'path';
   import fs from 'fs';
   
   /**
    * Normalize a Windows path to a canonical form.
    * Handles: \\?\ prefix, forward/backward slashes, case sensitivity,
    * short names, and trailing separators.
    */
   export function normalizeWindowsPath(inputPath: string): string {
     if (process.platform !== 'win32') {
       return path.resolve(inputPath);
     }
     
     let normalized = inputPath;
     
4. HeyDachui commented on May 28, 2026

   

   HeyDachui

   on May 28, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction from another local Codex Desktop install.

   I am seeing the same stale-path class of failure, but with one extra data point: offline normalization of the local state database does not persist after restarting Codex.

   Symptom

   Codex repeatedly fails to resume a running thread with a stale path error where the requested and active paths differ only by the Windows extended-path prefix:

   requested: C:\Users\<USER>\.codex\sessions\...
   active:    \\?\C:\Users\<USER>\.codex\sessions\...
   

   These point to the same file on Windows, but the resume guard appears to treat them as different paths.

   Scope observed

   This is not limited to one old or very large conversation. I have seen it affect:

   • newly created threads
   • threads already marked task_complete
   • currently running threads
   • session JSONL files that are not unusually large

   Local repair attempted

   With Codex fully exited, I performed two offline repair passes:

   1. Backed up and repaired state_5.sqlite
   2. Normalized threads.rollout_path and threads.cwd
   3. Backed up and reset Session Storage
   4. In the second pass, also backed up and reset Local Storage
   5. Did not delete any session JSONL files
   6. Did not clear the logs database
   7. Did not modify Codex configuration

   Immediately after the offline repair, the database looked clean:

   {
     "after": {
       "rollout_path_extended": 0,
       "cwd_extended": 0,
       "integrity_check": "ok"
     }
   }

   However, after restarting Codex, extended-path prefixes were written back into local state again:

   rollout_path_extended: 1
   cwd_extended: 77
   

   Interpretation

   This suggests the root cause is not only stale local user data. Codex itself appears to write some Windows paths back using the \\?\ form while resume requests may use the regular C:\... form. If the resume comparison happens before Windows path normalization, equivalent paths can be rejected as stale.

   Suggested product-side fix

   It would help if Codex normalized path identity before comparing:

   • threads.rollout_path
   • threads.cwd
   • active running thread path
   • branch/session restore path
   • recent/session restore path

   At minimum, if two paths differ only by \\?\ vs regular drive-letter form and resolve to the same file, resume should not be blocked as stale.

   I am not attaching raw logs or session files publicly because they may contain private local paths or credentials. I can provide redacted diagnostics if maintainers specify what would be useful.
5. lucaszengool

   added a commit that references this issue on Aug 13, 2026

   fix(windows): Codex attached once and never retried - Claude Code ret…

   ...

   0c807bb