Long Codex threads fail to hydrate after reload when compacted replacement_history records are large (UI shows empty, logs show missing handler) #19397

What version of the IDE extension are you using?

v26.422.21459

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.17.0-22-generic x86_64 x86_64

What issue are you seeing?

A Codex thread remains indexed in VS Code and its session file is valid JSONL, but reopening the thread results in an empty/unhydrated UI.

The thread appears normally in the UI list and is present in workspace state, but no messages are rendered when opened.

Extension logs show repeated:
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

This suggests a failure in the thread hydration/replay path rather than data loss.

What steps can reproduce the bug?

1. Start with a Codex thread that has grown long enough to trigger compaction.

   • The session JSONL contains at least one record:
     type: "compacted"
     with a large "replacement_history" payload.

2. Confirm the session file is valid JSONL and the thread is visible in the VS Code UI.

3. Reload VS Code (or close and reopen it).

4. Open the same Codex thread.

Expected:

• The thread should rehydrate and display prior messages.

Actual:

• The thread opens as an empty/unhydrated UI (no messages displayed).

Additional observation:

• Extension logs repeatedly show:
  [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

What is the expected behavior?

Reopening an existing Codex thread should reliably rehydrate and render the full prior conversation history in the UI.

Specifically:

• The thread should display previously exchanged messages.
• Hydration should succeed regardless of thread length or presence of compacted records.
• Stream/state update events (e.g., thread-stream-state-changed) should be handled by the UI layer and result in visible updates.

The presence of compacted records in the session JSONL should not prevent thread replay or rendering.

Additional information

Key observations from local inspection:

• The thread is present and indexed in VS Code workspace state.
• The session file is valid JSONL with no malformed lines.
• The target thread contains a compacted record with a large replacement_history payload (~200 KB).
• Across other sessions, compacted records can reach multi-megabyte sizes and represent a significant portion of total session size (30–40%+ observed).

Logs show repeated warnings:
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

This suggests that:

• The backend is emitting stream/state updates during hydration,
• But the UI layer is not registering or handling these events.

Hypothesis:
Long-thread replay combined with large compacted payloads may be triggering a failure in the hydration/update path, leaving the UI in an uninitialized state.

Additional note:
The underlying session data appears intact; this is not a data corruption issue but a hydration/rendering failure.

I can assist with further testing (e.g., modified session files with reduced replacement_history payloads) if helpful.

codex-thread-hydration-repro.tar.gz