›_ Codex Issues
Codex Issues / #23330

Status line can show a session ID that does not match the active chat/session

Resolved 💬 2 comments Opened May 18, 2026 by RealmX1 Closed Jun 5, 2026
💡 Likely answer: A maintainer (canvrno-oai, contributor) responded on this thread — see the highlighted reply below.

What happened

In a real Codex TUI session, I copied the session/conversation ID that was shown in the bottom status line and used it to investigate the current chat. The copied status-line ID was 019e25b6-5c....

When I later traced the same visible chat/turn through local Codex/RVF hook artifacts, the active parent chat consistently resolved to a different session ID: 019e3983-a93a.... For that same visible task/chat, the generated origin metadata contained:

parent_codex_url: codex://local/019e3983-a93a-...
parent_thread_id: 019e3983-a93a-...
parent_conversation_ref: Turn-Aware RVF Edit Claims

A local session file for the status-line ID prefix (019e25b6-5c...) did exist, but it belonged to a different older session. This sent debugging to the wrong transcript before the mismatch was noticed.

This may be related to multi-session/fork/resume state, but from a user perspective the problem is that the ID visible in the status line did not identify the active chat being operated on.

Expected behavior

The bottom status line should show the active chat/session/thread ID for the current TUI conversation, matching the ID used by local session artifacts, hook payloads, and any codex://local/... link for the active turn.

If the status line intentionally shows a different identity, such as a parent session, fork source, last-resumed session, or UI container session, it should be labeled distinctly so it is not used as the current chat ID during debugging.

Actual behavior

The status-line ID can appear to be stale or from a different session. In this case, copying the status-line ID led to a different local rollout/session file than the one referenced by the active chat metadata.

Why this matters

Session IDs are currently the most practical way to correlate:

  • a visible Codex TUI chat,
  • local ~/.codex/sessions/.../rollout-*.jsonl files,
  • hook payloads,
  • codex://local/... links, and
  • external automation logs.

If the status line can show a non-current ID, it makes bug reports and automation/debugging evidence unreliable.

Environment

  • Codex CLI: codex-cli 0.130.0
  • OS: macOS 26.3.1
  • Context: Codex TUI session launched inside an external task/worktree manager; the mismatch was observed while inspecting an automatically injected follow-up turn.

Related issues checked

I searched open issues for status-line/session-id mismatches and did not find an exact open duplicate. Related but not identical:

  • #6360 reported /status reflecting the newest login/current-session mismatch; it is closed.
  • #16560 discussed forked session IDs in /status; it is closed.
  • #16037 asks for machine-readable status output; it would help diagnose this, but it is not the same bug.

View original on GitHub ↗

2 Comments

canvrno-oai contributor · 3 months ago

@RealmX1 Thanks for the report. One thing I'd like to confirm: was the visible chat at that point a forked thread, and was the “different older session” you traced actually the parent thread it was forked from? I ask because the metadata you quoted (parent_codex_url / parent_thread_id) looks parent-thread-specific, so this would help me distinguish between:

  • The footer showing the current forked thread ID

vs.

  • The footer showing a genuinely stale or unrelated ID.
etraut-openai contributor · 3 months ago

I’m not able to verify this as a Codex bug from the current evidence.

The key detail is that the metadata cited here is explicitly parent_* metadata:

  • parent_codex_url
  • parent_thread_id
  • parent_conversation_ref

So comparing that ID to the footer/status-line ID may be comparing the parent thread to the currently displayed thread. In fork/subagent/side-thread flows, those are expected to differ.

I checked the TUI path: the status-line session-id/thread-id item is populated from the current ChatWidget.thread_id, which is set from the active ThreadSessionState.thread_id. Also, in 0.130.0, Codex hook session_id still used the concrete conversation/thread ID, so the evidence here looks more like external RVF/origin metadata pointing at a parent than Codex showing a stale footer ID.

One confusing bit is real: in 0.130.0 this status-line item was still labeled “session identifier” even though it represented the current thread ID. Current main has since renamed/described it as thread-id, which should reduce this confusion.

To move this forward, I’d need the raw artifacts:

  1. Was the visible chat forked, a side thread, or a subagent/thread-spawn child?
  2. Full footer ID and full parent_thread_id.
  3. The rollout paths/files for both IDs.
  4. Raw Codex hook payload showing session_id, thread_id if present, and subagent context.

Without that, I think this is likely a parent/current-thread mixup rather than a stale status-line bug.