Codex Version
v0.149.0
Change Description
- #39385 "Prefer the most recent session when queueing by name" (
codex-rs/tui/src/session_queue_commands.rs, codex-rs/tui/src/session_archive_commands.rs) changes queue-by-name resolution: when multiple sessions share a name, the TUI now picks the most recently active one instead of erroring on the ambiguity.
- #39034 "Dispatch queued messages written by other processes" (
codex-rs/ext/queue/src/service.rs, codex-rs/state/src/runtime/queued_items.rs) lets queued messages written by another process get dispatched.
- #39604 "Preserve queued TUI input semantics" (
codex-rs/tui/src/chatwidget/session_flow.rs, codex-rs/tui/src/chatwidget/slash_dispatch.rs) preserves existing queued-input behavior around this change.
Impact on codex-trace
A repo-wide search of src-tauri/src/parser and shared/types.ts found no existing code path or test that models TUI queue commands, queue-by-name resolution, or an expected "duplicate session name" error at all — codex-trace doesn't currently assume that error path anywhere. So there's nothing to fix on the parser side. The behavior change is still worth tracking because a duplicate-name queue dispatch that used to fail loudly will now silently apply to a specific (most-recent) session, which changes which session's rollout file receives the queued message — worth confirming codex-trace's session-discovery logic still correctly attributes the resulting turn to the right session file.
Severity: Moderate
Suggested Fix
Capture a real v0.149.0 session where two sessions share a queue name and a message is queued by name, and confirm the message lands in the rollout JSONL of the most-recently-active session as expected, with no stray/ambiguous session files. If session attribution is correct, no code change is needed — just document the behavior change. If codex-trace's session discovery ever special-cased queue-name ambiguity (it currently doesn't, per the search above), that logic would need updating.
Source
openai/codex#39385
openai/codex#39034
openai/codex#39604
Codex Version
v0.149.0
Change Description
codex-rs/tui/src/session_queue_commands.rs,codex-rs/tui/src/session_archive_commands.rs) changes queue-by-name resolution: when multiple sessions share a name, the TUI now picks the most recently active one instead of erroring on the ambiguity.codex-rs/ext/queue/src/service.rs,codex-rs/state/src/runtime/queued_items.rs) lets queued messages written by another process get dispatched.codex-rs/tui/src/chatwidget/session_flow.rs,codex-rs/tui/src/chatwidget/slash_dispatch.rs) preserves existing queued-input behavior around this change.Impact on codex-trace
A repo-wide search of
src-tauri/src/parserandshared/types.tsfound no existing code path or test that models TUI queue commands, queue-by-name resolution, or an expected "duplicate session name" error at all — codex-trace doesn't currently assume that error path anywhere. So there's nothing to fix on the parser side. The behavior change is still worth tracking because a duplicate-name queue dispatch that used to fail loudly will now silently apply to a specific (most-recent) session, which changes which session's rollout file receives the queued message — worth confirming codex-trace's session-discovery logic still correctly attributes the resulting turn to the right session file.Severity: Moderate
Suggested Fix
Capture a real v0.149.0 session where two sessions share a queue name and a message is queued by name, and confirm the message lands in the rollout JSONL of the most-recently-active session as expected, with no stray/ambiguous session files. If session attribution is correct, no code change is needed — just document the behavior change. If codex-trace's session discovery ever special-cased queue-name ambiguity (it currently doesn't, per the search above), that logic would need updating.
Source
openai/codex#39385
openai/codex#39034
openai/codex#39604