Codex Desktop replay/fork hides steered user messages and leaves some previous-message bodies expanded #19975

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Apr 28, 2026
2. github-actions commented on Apr 28, 2026

   

   github-actionsBot

   on Apr 28, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Show Q&A in session history on resume #19042
   • Codex desktop app shows verbose tool-trace rows in chat and hurts readability #18508

   Powered by Codex Action
3. libimor

   changed the title [-]Codex Desktop replay/fork hides steered user messages and does not collapse long tool logs[/-] [+]Codex Desktop replay/fork hides steered user messages and leaves previous-message history expanded[/+] on Apr 28, 2026
4. libimor

   changed the title [-]Codex Desktop replay/fork hides steered user messages and leaves previous-message history expanded[/-] [+]Codex Desktop replay/fork hides steered user messages and leaves some previous-message bodies expanded[/+] on Apr 28, 2026
5. Necmttn commented on Jun 21, 2026

   

   Necmttn

   on Jun 21, 2026

   More actions

   Replay/fork rendering should be derived from immutable message records, not from the current collapse state.

   Each message part needs role, source surface, turn id, parent id, steered/guided flag, and raw transcript offset. The renderer can collapse previous-history groups for readability, but user-authored steering messages should remain addressable and visible as first-class transcript events.

   ---

   Generated with ax.
6. StreamVi commented on Aug 24, 2026

   

   StreamVi

   on Aug 24, 2026 – with ChatGPT Codex Connector

   More actions

   I reproduced a stronger form of this on Windows Desktop where almost the entire visible history of a long active turn disappeared after reopening the task.

   Environment

   • Codex Desktop for Windows, AppX package 26.818.5229.0
   • Local Codex task backed by a WSL workspace
   • One long-running assistant turn with many user steering/follow-up messages

   Reproduction

   1. Start a task and keep the same assistant turn active for a long time.
   2. Send multiple follow-up/steering messages while that turn is still running.
   3. Later reopen the task, or navigate to another task and back.
   4. The task opens, but the accumulated conversation history is absent; only the beginning may be available.

   Diagnostic evidence

   • The task was still returned by the Desktop thread list with the correct title and status: active.
   • A direct read_thread call found only one inProgress turn containing the first user message and a few early items.
   • The page metadata simultaneously returned nextCursor: null and hasMore: false, even though many later steering messages and assistant responses had occurred.
   • navigate_to_codex_page returned navigated: true, but navigating away and back did not restore the missing transcript.
   • The active assistant still had enough effective context to reconstruct what had been discussed, so this looked like a retained-history/replay projection failure rather than the task itself being deleted.

   This appears consistent with the issue's missing steered-message replay, but the impact is broader: after reopening, the user can lose the visible audit trail for nearly the whole active turn, and the history API reports that no older page exists.

   Expected behavior

   Every accepted steering/follow-up message and its resulting assistant output should be durably represented in the replayable thread history. If an active turn cannot be fully rehydrated, Desktop should fetch/reconcile it from canonical history or show an explicit recovery error; it should not return hasMore: false for an incomplete projection.

   No private thread IDs, prompts, project names, or local paths are included here.
7. magiclinesofcode commented on Sep 25, 2026

   

   magiclinesofcode

   on Sep 25, 2026

   More actions

   Reproduced on 2026-09-25 with Windows Codex Desktop 26.917.8451.0 connected over Remote SSH to a Mac app-server 0.157.0. The same Mac app-server also owns iOS Remote, so there is no competing thread writer in this reproduction.

   During a long active turn, iOS submitted a follow-up accepted by the server as thread/queue/add followed by turn/steer. The iOS app displays the user message bubble. The canonical rollout and thread_history_1.sqlite both contain it as a userMessage item within that active turn (clientId is null). The history projection cursor is at the end of the rollout. Codex Desktop's task-history read API returns the userMessage and the following agent response. The Windows desktop UI displays the agent response and subsequent image previews but omits only the steered user message bubble.

   Switching to another task and back, and reconnecting only the Windows SSH transport, did not restore the bubble. A prior Windows-originated message that started its own turn, with a non-null clientId, appeared on both devices. This is a user-message rendering/replay failure, not message loss or stalled history projection, and appears to be the same failure reported in #19975 on a current desktop release.

   Please render persisted userMessage items that are steered into an active turn, including messages originating from iOS Remote. I can provide sanitized event IDs and timestamps privately if useful.
8. nie2894 commented on Oct 11, 2026

   

   nie2894

   on Oct 11, 2026 – with ChatGPT Codex Connector

   More actions

   Windows 26.1007.2314.0：运行中追加的 userMessage 被转换为仅有 steered 标记

   补充本版本的诊断与合成复现。测试输入均为合成资料，不包含用户原对话、截图、账号、线程ID或本机路径。

   当前实测

   • Windows MSIX版本26.1007.2314.0。
   • 三条实际受影响消息均是已完成轮中的非首条userMessage，clientId=null；各有文字与图片。消息存在于原始历史及历史读取接口；原生界面不能完整显示对应气泡和图片。
   • 可见的对照消息是独立执行轮的首条输入且有clientId。此相关性本身不是因果证明。
   • 原会话重开、新窗口、重启、展开旧消息、聊天内搜索跳转和复制Markdown均未验证恢复。没有改原会话记录或历史数据库。

   安装版转换逻辑的最小复现

   只读检查当前安装版：本地会话visibleTurnEntries的preserveServerUserMessages为false，aeon路径为true。userMessage转换分支存在以下行为：

   1. 首条输入已渲染，后续项是普通userMessage。
   2. 无匹配steeringUserMessage、非问答回复、非特殊事件，clientId为空。
   3. 在preserveServerUserMessages=false时，分支仅push steered标记，丢弃已经构建的用户气泡。

   从安装版抽取该case分支和去重辅助函数，在独立Node VM中运行；展示构造、策略过滤等非目标辅助函数用桩替代。因此这是精确分支复现，不是整个运行中应用的端到端复现。

   合成输入为一段文字和三张虚拟图片：原分支输出仅steered，文字false、图片0。候选条件让未去重的null-client服务端消息继续渲染用户气泡后，输出user-message（文字true、图片3）+steered。

   8个合成用例通过：空clientId图片追加、空clientId纯文本追加、非空clientId追加、preserve=true、首条消息去重、已匹配steering去重、初始clientId去重、助手回复后合法重复提问。

   建议维护者核对

   请在产品源码中保留未被首条输入或steering消息去重的持久化userMessage；不要把clientId为空作为隐藏气泡的依据。维持首条/steering去重、特殊消息过滤和搜索锚点一致性。检查本地会话preserveServerUserMessages=false的历史兼容目的，避免简单全局切换该标志造成重复。

   候选修正只在离线提取副本上验证，未修改签名安装包、原始历史或客户端数据库，未验证手机运行时。需要维护者提供正式修复或受支持的无损恢复入口，并验证原消息文字和图片在Windows及手机原时间线均可见。
9. vgeshel commented on Oct 20, 2026

   

   vgeshel

   on Oct 20, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Codex Desktop 26.1013.40934, observed October 19, 2026 (America/Los_Angeles). This instance concerns a cloud-backed Codex chat viewed in Desktop. The operating system was not collected.

   Observed behavior

   Two follow-up user prompts disappeared from the displayed conversation, while the assistant's separate final answers appeared consecutively in one response block. This makes the visible history look as though the assistant answered without the intervening corrections.

   A user-provided screenshot shows the first user prompt, one work/activity block, and both final answers, but omits the two intervening user prompts. The screenshot and private conversation text are not attached here.

   Stored record versus displayed history

   The Codex app's read_thread tool returned one completed turn containing three distinct userMessage items and two distinct agentMessage items with phase: final_answer, in this order (commentary and tool items omitted):

   userMessage A
   agentMessage final_answer A
   userMessage B
   userMessage C
   agentMessage final_answer B
   

   Both omitted user messages retained their complete text and distinct message IDs in that result. The visible Desktop timeline instead showed user A followed by answer A and answer B together, with B and C absent.

   This establishes a discrepancy between the readable stored chat record and the rendered conversation. It does not establish deletion from storage. This investigation used read_thread; it did not inspect the desktop renderer, local rollout files, or local databases.

   Observed sequence, not a clean minimal reproduction

   1. Use an ongoing Codex chat in Desktop.
   2. Send follow-up corrections while work is ongoing or transitioning after a visible final answer. The retrieved history groups these inputs into the same turn.
   3. Once work completes, inspect the displayed conversation.
   4. Compare it with read_thread: the latter contains the intervening user messages, while the UI omits them and combines the final answers.

   No fork or replay action was identified as a required trigger in this occurrence. Persistence across an app restart and recovery through Queue mode have not been tested.

   Expected behavior

   Render every accepted user-authored message at its chronological position, including follow-ups inside a turn, and retain the separation between assistant answers and intervening corrections. A single turn containing multiple user inputs and final-answer items should not become a transcript that omits those inputs.

   The previously discussed preserveServerUserMessages/null-clientId rendering path is a possible related mechanism, but it has not been verified on this installation. Private prompts, session IDs, repository details, and credentials are omitted from this report.
10. sunfloweeeeer commented on Oct 21, 2026

    

    sunfloweeeeer

    on Oct 21, 2026 – with ChatGPT Codex Connector

    More actions

    Additional observed case on macOS, possibly related to this issue.

    Environment:

    • ChatGPT/Codex desktop app: 26.1013.40934, build 20770, bundle com.openai.codex.
    • macOS 27.0.1, arm64.
    • Local desktop chat.

    Observed behavior:
    A short follow-up was submitted near the end of an active assistant turn. Its user-message bubble is absent from the desktop conversation. The assistant's first answer and its answer to the follow-up appear consecutively, with no user message separating them. The user provided a screenshot showing this and reported that closing/reopening the app did not restore the missing bubble.

    Read-only verification:

    • The desktop log records a successful turn/steer response (errorCode=null).
    • The persisted session JSONL contains the follow-up as a response_item message with role=user.
    • The subsequent assistant answer explicitly addresses that follow-up.
    • A thread/read inspection returns both user messages and both assistant answers within the same completed turn, in the expected event order.

    Sanitized relative timeline:

    • t=0: original turn starts.
    • t=21.2s: first assistant final_answer item is persisted.
    • t=21.9s: successful turn/steer response is logged.
    • t=24.1s: follow-up user message is persisted.
    • t=53.9s: second assistant final_answer item is persisted.
    • t=56.8s: the turn completes.

    This case establishes that the follow-up was persisted and answered; it is not a demonstrated loss of message data. The same-turn rendering/replay path is a candidate investigation area, not a confirmed code-level root cause. No fork operation is required by the observed sequence. A deterministic minimal reproduction has not been established.

    Expected: render every persisted user message in chronological order, including user input accepted via steering, and preserve those bubbles after reopening the chat.

    No conversation text, screenshot, raw logs, private paths, account details, or session identifiers are included in this public comment.