Codex Desktop session list appears to drop existing local transcripts after index rebuild/filtering

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

• #23193
• #24364
• #23126

Powered by Codex Action

1|# Codex #24521: Desktop Session List Drops Local Transcripts After Index Rebuild
2|
3|## Issue Summary
4|
5|Codex Desktop showed many older working sessions as missing even though the underlying local transcript files still existed on disk. This is a session index / sidebar visibility issue rather than transcript deletion.
6|
7|Evidence: 461 JSONL transcript files on disk, but only 245 visible in the session index (237 unique IDs). 224 transcript files not represented in the visible index. 217/223 missing files contained approval-reviewer/guardian policy markers.
8|
9|## Root Cause Analysis
10|
11|### Primary Cause: Index Filtering Over-Exclusion
12|
13|The session index rebuild process appears to filter out internal approval-reviewer / guardian-subagent transcripts. However, the filtering logic is too aggressive:
14|1. It excludes 217/223 files that are indeed internal guardian runs (correct behavior)
15|2. But it also excludes ~6 files that are real user-facing work or subagent investigation sessions (incorrect)
16|
17|The filtering likely uses heuristic markers (e.g., session metadata containing "approval-reviewer" or "guardian" strings) but doesn't properly distinguish between:
18|- Pure guardian runs: Internal-only sessions that should be hidden
19|- Mixed sessions: User-facing sessions that happened to trigger guardian review
20|
21|### Secondary Cause: Index-File Count Mismatch
22|
23|The session index has 245 entries representing 237 unique IDs — meaning 8 entries are duplicates. This suggests the index rebuild doesn't properly deduplicate entries, and the deduplication logic may be dropping valid entries.
24|
25|## Proposed Fix
26|
27|### Fix 1: Improve Filtering Logic to Distinguish Internal vs Mixed Sessions
28|
29|``typescript
30|interface SessionFilterResult {
31| shouldShow: boolean;
32| reason: string;
33|}
34|
35|function shouldShowSession(transcript: TranscriptFile): SessionFilterResult {
36| const meta = transcript.session_meta;
37|
38| // Pure guardian/approval-reviewer runs: hide from user session list
39| if (meta.agent_role === 'approval-reviewer' || meta.agent_role === 'guardian') {
40| // But show if this session also contains user-facing messages
41| const hasUserMessages = transcript.messages.some(
42| m => m.role === 'user' && !m.content.includes('[guardian]')
43| );
44| if (hasUserMessages) {
45| return { shouldShow: true, reason: 'mixed-session-with-user-content' };
46| }
47| return { shouldShow: false, reason: 'pure-internal-session' };
48| }
49|
50| // Subagent investigation sessions: show if they have meaningful output
51| if (meta.agent_role === 'subagent') {
52| const hasOutput = transcript.messages.some(m =>
53| m.role === 'assistant' && m.content.length > 100
54| );
55| return { shouldShow: hasOutput, reason: hasOutput ? 'subagent-with-output' : 'empty-subagent' };
56| }
57|
58| // Default: show all user-facing sessions
59| return { shouldShow: true, reason: 'user-session' };
60|}
61|`
62|
63|### Fix 2: Fix Index Deduplication
64|
65|`typescript
66|function rebuildSessionIndex(transcriptFiles: TranscriptFile[]): SessionIndex {
67| const seen = new Map<string, SessionIndexEntry>();
68|
69| for (const file of transcriptFiles) {
70| const meta = file.session_meta;
71| const id = meta.id || file.id;
72|
73| // Keep the most recent entry for each session ID
74| const existing = seen.get(id);
75| if (!existing || (meta.updated_at > existing.updated_at)) {
76| seen.set(id, {
77| id,
78| thread_name: meta.thread_name || file.title,
79| updated_at: meta.updated_at,
80| file_path: file.path,
81| is_archived: meta.archived || false,
82| should_show: shouldShowSession(file).shouldShow
83| });
84| }
85| }
86|
87| return { entries: Array.from(seen.values()) };
88|}
89|`
90|
91|### Fix 3: Add Index Integrity Verification
92|
93|`typescript
94|// Periodic check: compare disk files vs index entries
95|async function verifySessionIndexIntegrity() {
96| const diskFiles = await findTranscriptFiles();
97| const indexEntries = await loadSessionIndex();
98|
99| const indexedIds = new Set(indexEntries.map(e => e.id));
100| const missingFromIndex = diskFiles.filter(f => !indexedIds.has(f.id));
101|
102| if (missingFromIndex.length > 0) {
103| console.warn(${missingFromIndex.length} transcript files missing from index);
104| // Auto-rebuild for missing files
105| for (const file of missingFromIndex) {
106| const entry = buildIndexEntry(file);
107| if (entry.should_show) {
108| await addToIndex(entry);
109| }
110| }
111| }
112|}
113|`
114|
115|### Fix 4: Add User-Facing "Show Hidden Sessions" Toggle
116|
117|`typescript
118|// In session list UI
119|interface SessionListConfig {
120| showInternalSessions: boolean; // Default: false
121| showArchivedSessions: boolean; // Default: false
122|}
123|
124|// Allow users to see all sessions including filtered ones
125|function getSessionList(config: SessionListConfig): SessionIndexEntry[] {
126| const allEntries = loadSessionIndex();
127| return allEntries.filter(e => {
128| if (!config.showInternalSessions && e.is_internal) return false;
129| if (!config.showArchivedSessions && e.is_archived) return false;
130| return true;
131| });
132|}
133|``
134|
135|## Implementation Priority
136|
137|1. P1 (Important): Improve filtering logic — prevents over-exclusion of valid sessions
138|2. P1 (Important): Fix index deduplication — prevents duplicate/dropped entries
139|3. P2 (Enhancement): Index integrity verification — auto-recovery from index corruption
140|4. P2 (Enhancement): User-facing toggle — gives users control over visibility
141|
142|## Testing Plan
143|
144|1. Filtering tests: Verify guardian-only sessions are hidden, mixed sessions are shown
145|2. Dedup tests: Verify index has exactly one entry per session ID
146|3. Integrity tests: Verify missing files are detected and re-indexed
147|4. Regression tests: Verify existing visible sessions remain visible
148|
149|## Impact
150|
151|- User impact: HIGH — Users lose access to their session history
152|- Data loss risk: LOW — Files exist on disk, just not visible in UI
153|- Scope: Medium — Affects all users with many sessions (especially heavy automation users)
154|- Fix complexity: LOW — Filtering logic + dedup, ~150 lines total
155|

Adding another concrete data point from Codex Desktop on macOS.

This looks like the same class of issue: a completed, user-facing project session has a valid local JSONL transcript, but it is not discoverable in the Codex Desktop project thread list or via the thread search/list API.

Environment

• Codex Desktop app version observed in local app logs: 26.527.60818
• CLI version in transcript metadata: 0.136.0-alpha.2
• OS: macOS
• Timezone: Asia/Kolkata
• Session source in metadata: vscode
• Originator in metadata: Codex Desktop
• thread_source: user
• Session cwd: a saved local project repo under ~/Developer/...

Missing session

• Thread id: 019e86c3-ee54-7fa1-a2af-0f4e80917d27
• Local transcript path, redacted:

~/.codex/sessions/2026/06/02/rollout-2026-06-02T10-47-28-019e86c3-ee54-7fa1-a2af-0f4e80917d27.jsonl

• Started: 2026-06-02T05:17:28Z
• Completed: 2026-06-02T05:39:24Z
• Transcript size: about 1.2 MB
• Transcript line count: 519

The transcript ends normally with task_complete, followed by a final session_meta record. It does not look corrupt or incomplete.

What makes this one useful to debug

This was not an old historical session after an app update. It was a fresh session created and completed on the same day.

The session:

• started on one git branch,
• updated/switched branch state during the task,
• created a new feature branch,
• left uncommitted working-tree changes,
• completed normally,
• and wrote a valid local transcript.

The final transcript metadata still has the same thread id and cwd, with updated git branch metadata.

App/API search behavior

The Codex app thread search/list API returned no results for exact searches including:

• the exact thread id: 019e86c3-ee54-7fa1-a2af-0f4e80917d27
• the created branch name
• exact phrases from the final assistant response
• exact phrases from the task prompt

Nearby sessions for the same project and with the same source: "vscode" are visible/searchable, so source: "vscode" alone does not explain this.

Expected

A completed thread_source: "user" session with:

• valid local JSONL transcript,
• project cwd,
• completed task,
• and normal final metadata

should be visible under the project, or at minimum discoverable by exact thread id.

Actual

The local transcript exists and the code changes exist, but the session is missing from normal project navigation and search/list results. From the user perspective it looked like the completed Codex session had disappeared.

This seems like a local transcript persistence vs app/project thread index mismatch, potentially triggered by branch/project metadata changes during the session or by index filtering after completion.

Adding another concrete data point, this time from Codex Desktop on Windows/WSL.

This looks like the same class of issue: user-facing local project threads are still present locally and can be loaded by exact thread id, but they are not discoverable through the Desktop/project thread search/list path.

Environment:

• Originator in transcript metadata: Codex Desktop
• CLI version in transcript metadata: 0.136.0-alpha.2
• Platform: Windows app using a WSL local project
• Session source in metadata: vscode
• thread_source: user

Observed:

• Four expected user-facing threads named like Fix #<issue> ... disappeared from the Desktop thread list/search and were not in the archived view.
• Exact thread searches for the issue numbers and PR/title keywords returned no results.
• The same thread ids were still present in session_index.jsonl.
• The rollout files were still in normal sessions/, not archived_sessions/.
• Direct thread-id loading succeeded for each hidden thread.
• Re-running thread search/list after direct loads still returned no results.
• Pinning those exact thread ids made them recoverable/visible, which suggests pinned threads bypass the broken discovery path.

Hidden but valid examples:

• 019e60a8-34db-7932-b815-2165a9d7881e — Fix #14861 waiting
• 019e6036-d736-72c0-aec9-3803910d63d5 — Fix #69192 waiting
• 019e61f4-e49e-72a3-97ec-6f7c1d74475e — Fix #50621 waiting
• 019e6e4c-afd2-7eb2-8cd5-de6f78d5c8aa — Fix #70903 waiting

Control examples from the same project that remained discoverable:

• Fix #78492 waiting
• Fix #62432 waiting
• Fix #61569 conflict
• Fix #66936 waiting

This makes the failure look narrower than transcript loss: the canonical/local data is present and readable, but Desktop sidebar/search/list hydration omits some valid non-archived user threads. A useful fix would be for sidebar/search to paginate or query the canonical local thread/session source directly, and for direct thread-id recovery to refresh project/sidebar membership instead of requiring manual pinning.