openai / openai/codex

[Bug] Windows Desktop loses conversation UI after turns remain permanently inProgress despite complete JSONL projection

Open
#45,431 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug session windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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

26.908.4834.0

What subscription do you have?

Pro 20x

What platform is your computer?

Windows x64

What issue are you seeing?

Codex Desktop on Windows repeatedly loses the visible conversation history.

This initially happened on a long-running task, so I suspected the thread was simply too large. However, I created a fresh continuation thread and the same problem reproduced within minutes.

The underlying conversation data is still present in the rollout JSONL and in thread_history_1.sqlite. Read-only inspection suggests that the history projection successfully reaches EOF and materializes thread items, but the turns never receive terminal lifecycle events and remain permanently inProgress.

This appears to be more specific than simple JSONL loss or a stalled projection.

What steps can reproduce the bug?

I opened a new Codex Desktop conversation for a local coding project and continued working normally.

Within minutes, the conversation content disappeared from the Desktop UI.

The thread's rollout JSONL still existed and continued to contain the user messages, assistant messages, reasoning records, and command executions.

Creating another new conversation did not solve the problem.

Fresh-thread evidence

The affected fresh rollout was only approximately:

3,409,003 bytes

It contained:

113 records

with ordinals:

0 ... 112

The JSONL parsed successfully.

The history projection state for the same sanitized thread reported:

next_rollout_byte_offset = 3409003
next_rollout_ordinal = 113

Therefore the projection cursor had reached the exact end of the rollout file.

What is the expected behavior?

No response

Additional information
SQLite health

thread_history_1.sqlite size:

2,411,663,360 bytes

Read-only SQLite checks:

PRAGMA quick_check = ok
page_size = 4096
page_count = 588785
freelist_count = 0

Tables include:

thread_history_projection_state
thread_turns
thread_items
thread_realtime_items

Therefore this does not appear to be basic SQLite physical corruption.

Materialized history exists

The affected thread exists in thread_history_projection_state.

thread_items also contains the expected materialized content, including:

user messages
assistant/agent messages
reasoning items
command executions

For the first turn, the projected items included:

1 userMessage
5 agentMessage
11 reasoning
13 commandExecution

So the conversation content is not missing from the underlying history store.

Suspected lifecycle problem

The rollout contained two separate lifecycle starts:

First turn:

task_started
at rollout ordinal 1

Second turn:

task_started
at rollout ordinal 98

However, the entire rollout contains no matching:

task_complete
turn_complete
turn_completed
turn_aborted
task_aborted

events.

The corresponding rows in thread_turns remain:

status = inProgress
completed_at = NULL
final_agent_item_id = NULL
rollout_end_ordinal = NULL
rollout_end_byte_offset = NULL

This is true for both turns.

The second turn was accepted even though the first turn remained permanently inProgress.

Observed behavior

The runtime can write messages and tool execution records successfully.

The rollout JSONL remains valid.

The history projector reaches EOF.

The thread items are materialized correctly.

But the Desktop conversation eventually becomes empty / unavailable in the UI.

Expected behavior

If a turn is interrupted, abandoned, disconnected, or superseded by a later user turn, Codex should persist an appropriate terminal/interrupted lifecycle state.

A stale inProgress turn should not cause subsequent conversation history to disappear from the Desktop UI.

Additional notes

I also reproduced the issue after abandoning a previous much larger conversation and starting a fresh one, so this does not appear to require a very large transcript or context compaction.

I made read-only SQLite backups before inspection and did not manually modify the Codex databases.

Related issues may include:
#44362
#44035
#40779

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how rollout JSONL lifecycle events update the thread_turns and thread_history_projection_state tables, using the reported thread_items and thread_realtime_items rows as evidence. Reproduce the case with a fresh thread and inspect the two task_started events and missing terminal events. Done means interrupted, abandoned, disconnected, or superseded turns receive an appropriate terminal state and the Desktop UI retains the materialized conversation history.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, sqlite
Domain
databases, desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.