›_ Codex Issues
Codex Issues / #19569

Codex VS Code thread title renders but body is empty.

Open 💬 5 comments Opened Apr 25, 2026 by ttasovac
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

openai.chatgpt 26.422.30944-darwin-arm64

What subscription do you have?

Pro

Which IDE are you using?

VS Code

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

A Codex VS Code thread opens with the correct title, but the conversation body is empty, so I cannot inspect or continue the thread from the IDE.

What I checked locally:

  • The transcript file exists:

~/.codex/sessions/2026/04/25/rollout-2026-04-25T12-33-16-019dc433-672c-74b0-8439-a04b145add41.jsonl

  • The JSONL validates successfully with jq -c . file >/dev/null.
  • Codex SQLite state points to that file.
  • The thread is not archived.
  • The VS Code UI renders the title but no messages.

SQLite row:

id=019dc433-672c-74b0-8439-a04b145add41
title=Scaffold vukomat existdb upgrade
archived=0
source=vscode
cwd=/Users/ttasovac/Development/ttasovac/raskovnik-frontend
cli_version=0.125.0-alpha.3

One suspicious detail: the threads.has_user_event value is 0 even though the transcript JSONL contains user messages.

What steps can reproduce the bug?

I can provide the affected local transcript privately if useful.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19397
  • #19478
  • #19434
  • #18931

Powered by Codex Action

daxliniere · 4 months ago

YES THIS IS KILLING ME. @MODS, come join the Codex Discord and for plenty of reports of this and other issues since 5.5 dropped.

metrax · 4 months ago

Have a look to my workaround here:
https://github.com/openai/codex/issues/18993#issuecomment-4312587938

daxliniere · 4 months ago
Have a look to my workaround here: https://github.com/openai/codex/issues/18993#issuecomment-4312587938

Hopefully that means it'll be a quick fix.

johnsilvavlogs · 2 months ago

I hit what looks like the same class of bug, but from Codex Desktop opening a CLI-origin managed thread via codex://threads/<id>.

User-visible symptom:

  • The thread appears in Codex Desktop with the expected title.
  • Opening codex://threads/<thread-id> makes it look like there is no work/history in the thread.
  • The actual transcript on disk contains all messages, tool calls, validations, commits, PR/deploy work, and production verification.

Local evidence, sanitized:

  • threads.rollout_path points to an existing JSONL under ~/.codex/sessions/.../rollout-...-<thread-id>.jsonl.
  • threads.source = cli
  • threads.archived = 0
  • threads.has_user_event = 0
  • threads.first_user_message and threads.preview are populated with the initial prompt.
  • threads.updated_at advanced during the work.
  • The JSONL session_meta.payload.id matches the thread ID in SQLite.
  • The JSONL parses successfully and contains:
  • response_item: 644
  • event_msg: 285
  • turn_context: 2
  • response messages by role: developer=1, user=8, assistant=112
  • event messages include user_message=3, agent_message=112, task_complete=2

Concrete impact:

  • The user reasonably concluded that the managed thread was not doing any work.
  • Inspecting the JSONL proved the thread had actually done substantial work, including tests, PR merge, Vercel production deploy, and production render verification.

Why this seems related:

  • The suspicious bit matches this issue: has_user_event=0 despite user messages existing in the transcript.
  • The app/IDE surface appears to rely on indexed SQLite/display metadata in a way that can produce an empty body, while the JSONL transcript remains the source of truth and is readable.

Possible area to inspect:

  • Hydration/rendering path for CLI-origin threads opened by deep link.
  • Any filter or early-empty-state branch that treats has_user_event=0 as "no conversation" even when rollout_path points to a valid transcript with response_item messages.
  • Backfill/indexing logic that sets has_user_event for CLI sessions with event_msg.user_message and/or response_item user messages.

Environment details I can share safely:

  • Codex CLI/app metadata in the row: cli_version=0.138.0-alpha.7
  • Platform: macOS
  • Thread source: cli

I can provide more sanitized row/schema details if useful.