Skip to content

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

Open
Open
Codex Desktop replay/fork hides steered user messages and leaves some previous-message bodies expanded#19975
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@libimor
libimor
opened on Apr 28, 2026

Summary

Codex Desktop appears to have a replay/fork rendering issue for local session history:

  1. Mid-turn steered/guided user messages are present in the raw session JSONL, but the Desktop UI can omit the user message bubble when replaying the session history or viewing a forked session.
  2. When replaying, reopening, or forking an existing session, some prior message bodies are not consistently collapsed into the compact previous messages/earlier messages history UI. Instead, individual message bodies from the previous history can remain expanded inline, making the resumed or forked session harder to inspect.

This looks like a UI/session replay bug rather than data loss: the raw JSONL still contains the relevant user messages and history entries.

Environment

  • App: Codex Desktop
  • Version observed: 26.422.3464.0
  • Platform: Windows
  • Session source in JSONL metadata: vscode
  • CLI version in JSONL metadata: 0.125.0-alpha.3

What I observed

During an active assistant turn, I sent a steering message. The raw session JSONL contains both entries for the message:

{
  "type": "response_item",
  "payload": {
    "type": "message",
    "role": "user",
    "content": [
      {
        "type": "input_text",
        "text": "<redacted steering message>\n"
      }
    ]
  }
}

and:

{
  "type": "event_msg",
  "payload": {
    "type": "user_message",
    "message": "<redacted steering message>\n",
    "images": [],
    "local_images": [],
    "text_elements": []
  }
}

However, when viewing the session in Codex Desktop, the UI may show the steering marker/status area and then the following assistant response, while the actual user bubble is missing.

I also reproduced this around session branching/forking. The forked session JSONL includes:

{
  "type": "session_meta",
  "payload": {
    "id": "<fork-session-id>",
    "forked_from_id": "<original-session-id>"
  }
}

The copied history in the fork still contains the same response_item user message and event_msg:user_message records. A thread_rolled_back event appears after the copied history and before the new branch turn:

{
  "type": "event_msg",
  "payload": {
    "type": "thread_rolled_back",
    "num_turns": 1
  }
}

In the Desktop UI, that forked/replayed history can still omit the guided/steered user bubble even though the raw data is present.

Separately, historical message content around replay/fork/resume is not consistently collapsed. I expected prior history to be hidden behind the compact previous messages/earlier messages affordance. Instead, some individual message bodies from the prior history can remain expanded inline, including normal assistant/user text and surrounding historical context. The core problem here is not command output verbosity; it is that some message bodies from previous history are not collapsed as previous-history content.

Expected behavior

  • If the JSONL contains a user steering message as response_item with role=user and/or event_msg:user_message, the Desktop replay should render the corresponding user bubble.
  • Forked sessions should render copied historical steered/guided messages the same way the original session does.
  • When reopening, replaying, or forking a long session, prior message bodies that belong to collapsed history should remain behind the normal previous messages/earlier messages UI instead of expanding inline.

Actual behavior

  • The raw JSONL contains the steered/guided user message, but the Desktop replay/fork UI can omit the user bubble.
  • Forked session history appears to be reconstructed around copied history plus thread_rolled_back, and that path seems to lose some rendering state for steered/guided messages.
  • Some previous-history message bodies can remain expanded inline instead of being collapsed into the compact previous-message/history block.

Notes

I found related public issues around steering, queued prompts, compaction, conversation-state desync, and fork/resume history, but I did not find an exact duplicate for this specific Desktop replay symptom where the raw user message exists and only the rendered bubble is missing.

Related examples I found:

The key diagnostic point is that this does not appear to be session data loss. It appears to be a renderer/replay conversion issue for Desktop session history, especially around steered/guided messages, fork/rollback reconstruction, and previous-history message body collapse state.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Apr 28, 2026

  2. github-actions commented on Apr 28, 2026

    @github-actions
    github-actionsBot
    on Apr 28, 2026 – with GitHub Actions
    Contributor

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

    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
    Necmttn
    on Jun 21, 2026

    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
    StreamVi
    on Aug 24, 2026 – with ChatGPT Codex Connector

    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
    magiclinesofcode
    on Sep 25, 2026

    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
    nie2894
    on Oct 11, 2026 – with ChatGPT Codex Connector

    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及手机原时间线均可见。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions