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

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.