Leak of internal reasoning and premature plan interruption in Codex output

What version of Codex CLI is running?

0.128.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Linux 6.19.11-1-liquorix-amd64 x86_64

What terminal emulator and version are you using (if applicable)?

Gnome-Terminal

What issue are you seeing?

I accidentally switched to final; need continue work not final. But system now final sent to user maybe undesirable. We can continue now as user
hasn't responded. We need adhere to commentary updates. We'll proceed.

Need inspect if there is method to set container list item maybe from static dynamic not available when selection changes. But HasFocus(item)
for static uses selected snapshot's properties Id first; if snapshot stale from previous selection then immediate container state may not be
enough? In provider resolve_container hasfocus target item:

if snapshot static with Id parse -> compare item_id == target_item and return.
if snapshot.position == target_item return true.
fallback state.position + (1?) etc.

So if selected snapshot stale, for static list still might use stale Id and return wrong. In SettingsProfile static list item ids are 1 and 2
from xml static items. If selected second, stale snapshot first would map Id=1 and wrong visible branch. fallback may use state.position maybe
if use_one_based=true and target_item=2 then state.position+1==2 if updated. But because code returns early when snapshot static and has item_id
parse: it returns item_id==target_item, ignoring state fallback. So stale snapshot will cause wrong branch regardless state update. Need
immediate sync must include selected list item snapshot to container_list_item for list id. Harder.

Need update selection-changing functions to update container list item snapshot too for static and dynamic lists maybe via helper.

There may be helper function to set list item context quickly from controls etc. Could implement function in focus_targets_runtime/
list_nav_runtime to update provider container_state and selected snapshot when selection changes and list data available there. We can call
collect_visible_static_items and dynamic_list_entries maybe expensive but fine.

Where to place helper? maybe new function in window_runtime_containers not accessible due module includes maybe pub(super). Could create in
list_runtime maybe there is function. let's inspect list_runtime.rs maybe helper. 계속. We'll send commentary update before exploring
substantial. +#+#+#+#+#+assistant to=functions.exec_command մեկնաբանություն สามสิบเอ็ดjson
{"cmd":"sed -n '1,320p' crates/museum-launcher-app/src/list_runtime.rs","workdir":"/media/Dev/Linux/project/","max_output_tokens":12000}

What steps can reproduce the bug?

Uploaded thread: 019de2a8-c138-7901-959b-2751db51ba4f

What is the expected behavior?

Expected behavior: the model should never expose internal reasoning or debug traces, must continue executing the plan until completion, and return only a clear, structured, and actionable final answer.

Additional information

The issue occurred during an ongoing plan execution where the model unexpectedly switched to a “final” state, leaked internal debugging reasoning (including code inspection steps), and interrupted the workflow before completion; the exposed reasoning also indicates a potential logic flaw where a stale snapshot is prioritized over the actual container state, causing incorrect item selection.