Subagent TUI corrupts live message text while raw rollout is correct

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #13686
• #14768

Powered by Codex Action

Third 0.115.0 reproduction from subagent session 019cfdea-d46c-7233-bcbd-0fa91851dd72.

This one is stronger than the previous two because the TUI appears to have visually fused two separate clean commentary messages into one garbled block.

Raw rollout contains these two distinct commentary messages:

Вношу две узкие правки в tooling docs: уточняю исключение для `Architect initial draft` и добавляю owner-facing инструкцию по `racex_plan_bundle`. После этого синхронизирую mirror `docs/plans/README.md` в sibling `racex`.

Mirror-патч не прошёл через `apply_patch`; tooling-файл отдельно дожму сейчас, а для sibling mirror, если понадобится, пойду через явное разрешение на один безопасный sync-патч.

But the live TUI showed a mangled block roughly like:

ношу две узкие правки в tooling: уточняю исключение Architect initialля owner-facing инструкцию по racex_plan_bundle. синхронизир mirror /.md ex.Точечно чиню
формулировку и пробую сразу же синхрон mirror-патч в ~/racex/plans/README.md. Если sandbox не даст писать sibling repo, запрошу отдельноеение на mirror.Mirror-
патч неёл через apply_patch; tooling-файл отдельно дожму сейчас, а для sibling mirror, если понадобится, пой через явное разрешение наный syncатч.

So this is not just a single-line character drop. In this repro the subagent UI surface appears to merge adjacent commentary items and then corrupt characters/whitespace/inline-code boundaries while rendering them.

Additional reproduction from subagent session 019d014d-b995-7741-9eb9-edd0de5212a1 (codex-cli 0.115.0, gpt-5.4, originator=codex-tui, source.thread_spawn, worktree codex-session-router).

This one is useful because it happened right after an image-review workflow.

What happened:

• the owner provided screenshots by absolute filesystem path (for example /Users/.../Снимок экрана ... .png)
• view_image succeeded on those files, so local image-by-path inspection was working
• the final subagent message stored in the raw rollout is clean and semantically correct
• but the visible TUI/app subagent surface rendered that same message as corrupted text:
• code fences / inline code boundaries were broken
• lines were fused together
• leading path characters were visually dropped
• the visible text changed meaning (contains no valid profiles appeared as contains valid profiles)

Raw rollout message:

Да, это уже реальный blocker.

Что видно сейчас:
- проблема с путями исправлена;
- новая ошибка другая: роутер не находит ни одного валидного auth-профиля.

Лог menubar app теперь такой:
auth pool at `/Users/palvaleri/codex-session-router/var/auth` contains no valid profiles

И я проверил сам `var/auth`:
- там есть только `README.md`
- ни одного профиля/`auth.json` там нет

Поэтому `Start` сейчас не может пройти в принципе. Это уже не UI-мелочь, а реальный runtime blocker для шага `running state`.

So this is another case where:

• raw rollout is correct
• displayed subagent text is corrupted
• this happens in a spawned subagent, not the main thread

Related observation (more tentative):

• in the same workflow the user reported clipboard-image paste was not working, so screenshots were passed by path instead
• the rollout for those user turns shows images=[] and local_images=[], while view_image on explicit PNG paths works
• I cannot prove the clipboard bug from rollout alone, but this reproduction is at least compatible with a broken image-attach/input path plus the already-known subagent render corruption

'
Would you like to make the following edits?

Thread: Fermat [working_high]

Reason: command failed; retry without sandbox?' so how i can fix this issue?

Additional data point from local Linux/native TUI usage:

• Main thread rendering stays clean even when switching away and back.
• The corruption shows up specifically when switching into spawned subagent threads and reading their reconstructed history/UI surface.
• The raw child rollout/session logs remain correct; the visible subagent surface is what becomes garbled.
• This makes it look less like bad model output and more like a subagent replay/render path bug.

Current hypothesis from reading the TUI source:

• Inactive subagent threads are buffered in ThreadEventStore and rebuilt on switch via replay_thread_snapshot(...).
• During replay, AgentMessageDelta still flows through the normal streaming path (handle_codex_event_replay -> on_agent_message_delta -> streaming controller / commit tick), instead of rendering only finalized transcript cells.
• That would explain why the main thread is usually fine while switched-to subagent threads show fused / dropped / punctuation-damaged text even though the raw rollout is correct: the subagent view is being visually restreamed during reconstruction.

So the likely fix area seems to be thread-snapshot replay for subagents:

• either materialize finalized assistant transcript content directly during replay,
• or suppress the live streaming/commit-animation path while reconstructing a switched thread.

I did not see evidence that this requires fork_context=true; the same visible corruption reproduced for me after explicitly steering supervisors to spawn workers with fork_context=false.

@palvaleri @ignatremizov @YoloMark98 this has been fixed on 0.116.0. Can you please retest and confirm you can no longer replicate this issue?

@fcoury you refer to:

• 78e8ee459: fix(tui): restore remote resume and fork history (#14930)
• 57f865c06: Fix tui_app_server: ignore duplicate legacy stream events (#14892)
• b0236501e: Remove legacy app-server notification handling from tui_app_server (#15390)

So far, I have not observed the issue again... I think I made my comment while on 116, although I might have been running the thread still on 115 before I restarted. I'm also not sure how the codex-rs/tui or codex-rs/tui_app_server paths are chosen right now, maybe it is still present on one or the other still. I'll be sure to report if I hit it again.

https://github.com/ignatremizov/codex/commit/2523697dcb8287cc86c743ae7e17ffdebd700fa9 might still be a useful hardening, codex gpt 5.4 was working on hardening the agent-switch rollout TUI and added this

Retested on codex-cli 0.116.0 on macOS after updating locally.

I can confirm I am no longer seeing the subagent text-corruption / garbled-live-render issue that this ticket was about. I am switching into subagents and the previous “кашеобразный” broken rendering is gone for me.

So from my side this now looks fixed in 0.116.0. Thanks — this was genuinely painful to work with before, and the difference is immediately noticeable.

Confirmed fixed on local retest with codex-cli 0.116.0. Thank you.

Reproduced on 2026-07-19 in the Codex desktop app on Windows 11 during a long conversation with subagents and repeated tool calls.

Observed two related presentation failures in the same session:

1. Internal orchestration output that would normally be folded into the tool trace was rendered directly in the conversation, including a failed tool invocation and a very large tool-metadata dump.
2. An assistant progress message contained an unrelated non-Chinese fragment in the middle of otherwise valid Chinese text. This happened again in the same session and was visible to the user, so it was not just a terminal encoding issue in a subprocess.

The conversation had recently used subagents and had accumulated a long context. The bad text appeared in the Codex UI. No repository file or shell output contained that fragment.

This looks close to #15001's presentation-layer symptoms, but the current occurrence is in Codex desktop rather than the TUI and is not limited to switching away from and back to a subagent. It may be useful to check whether the desktop app and TUI share the same event reconstruction / streaming path.

Expected: assistant text and tool trace remain separate; failed orchestration calls stay in the tool trace and assistant text is rendered byte-for-byte as generated.

Privacy note: I have omitted user content, local paths, credentials, and the full tool metadata dump. I can provide a sanitized screenshot or diagnostics if a maintainer identifies the preferred collection path.

Environment detail from the affected run: Windows 11; Codex desktop package version 26.715.4045 (identified from the installed package path). The built-in executable could not be queried directly because WindowsApps denied direct execution outside the packaged app context.