unified exec command can disappear when an exploring exec cell is active which hides ran commands from end users and is very misleading

Summary

A unified-exec command can execute successfully but never render in the TUI transcript when its begin event is intentionally skipped (non-standard/Unknown parsed command) and an unrelated exploring ExecCell is still active.

Minimal repro prompt

Run in order in distinct exec_command tool calls:
1) cat /dev/null
2) echo "repro-marker"

Do not send anything to the commentary channel between steps.

Then reply with exactly: done

(you can add even more commands if you'd like after step 2 or replace step 2 itself (even destructive commands like rm and etc.), and they will too be omitted from view, actively misleading you regarding what the agent ran).

It's important you make sure the agent doesn't send any commentary. This prompt has worked ten times in a row for me, but GPT-5.3-Codex has some of the most egregious commentary-specific prompting I've ever seen, so it does overwhelmingly ignore instructions to not send commentary (another pain point for me - but besides the point here).

Observed behavior

The second command executes successfully but does not appear in transcript history. Only the earlier exploring command can remain visible.

Expected behavior

Both commands should appear in transcript history:

• the exploring entry from cat /dev/null
• the completed command entry for echo "repro-marker"

Root cause

ExecCommandEnd handling in ChatWidget only checked whether the active cell was an ExecCell, not whether that ExecCell actually contained the ending call_id.

When a non-standard unified command has its begin suppressed, its end event arrives with no matching call in the active exploring cell. complete_call becomes a no-op on the wrong cell and the event is effectively dropped.

Debug evidence

The missing command still emits ExecCommandEnd with a successful exit_code (0), so execution succeeds but rendering is lost.

Proposed fix

Make ExecCommandEnd handling call-id aware:

• if active cell is an ExecCell and already contains the ending call_id, complete it in place
• if active cell is an ExecCell but does not contain call_id and has another still-running call, render this end event as a standalone orphan history entry without flushing the running cell
• otherwise flush the active exec cell and create/complete/flush a new exec cell from the end event payload

Regression coverage

Add tests for:

• orphan ExecCommandEnd while an exploring ExecCell is active
• orphan ExecCommandEnd does not flush an unrelated running ExecCell
• overlapping exploring calls do not misclassify a tracked end as orphan
• the unified unknown-command sequence above, verifying both commands render

I already have this fix and tests prepared locally.

This is an incredibly infuriating bug as I only found it out when the model ran multiple destructive commands after an exploring block and all of them were omitted from both the normal view and transcript view, completely misleading me.

I actually experienced this same behavior in the past since the launch of GPT-5.3-Codex, but I just put it down to the model hallucinating tool calls. Turns out it was actually a pretty sinister bug within Codex itself.

@joshka-oai @etraut-openai can I please open a PR ASAP for this with my fixes as this genuinely degrades trust (at least for me). Code review w/ GPT-5.3-Codex xhigh for my local fix:

**Code Review (latest commit `0d613ff82`)**

1. No blocking regressions found in the code change itself.
2. The issue you described is fixed correctly and robustly:
   - Call-id-aware mismatch handling is now in `codex-rs/tui/src/chatwidget.rs:2370`.
   - The added safeguard for unrelated *running* exec cells is in `codex-rs/tui/src/chatwidget.rs:2341`, which avoids prematurely flushing in-flight commands.
3. Regression coverage is strong and directly relevant:
   - `codex-rs/tui/src/chatwidget/tests.rs:3222`
   - `codex-rs/tui/src/chatwidget/tests.rs:3288`
   - `codex-rs/tui/src/chatwidget/tests.rs:3390`
   - `codex-rs/tui/src/chatwidget/tests.rs:3487`
   - snapshot: `codex-rs/tui/src/chatwidget/snapshots/codex_tui__chatwidget__tests__unified_exec_unknown_end_with_active_exploring_cell.snap`

I've had a couple PRs merged in the past. Let's try get this issue fixed quickly please!