Codex Desktop conversations become empty and resume fails with stale Windows path

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

• #23900
• #22971
• #23803
• #23311
• #23979

Powered by Codex Action

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

Issue: https://github.com/openai/codex/issues/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;
  

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.

This is a strong local-state mismatch: 270 active rollout files still exist, SQLite references none as missing, but equivalent C:\... and \\?\C:\... spellings make resume reject the same file as stale and many chats appear empty.

I’m testing Codex Rescue against this boundary. It scans rollouts independently and leaves SQLite, session_index.jsonl, and source files untouched. It cannot fix Codex’s Windows path comparison or rebuild the Desktop UI, but it may identify the durable sessions and report their state safely.

Could you try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output is enough—please don’t share raw rollouts, databases, logs, usernames, prompts, paths, API keys, or secrets.

https://github.com/shleder/codex-rescue