`codex exec resume` can append to a Desktop session transcript without updating the Desktop session index/UI reliably

What version of Codex are you using?

codex-cli 0.140.0-alpha.2

The affected session was originally created from Codex Desktop. I do not want to
include raw session ids or local transcript excerpts in the public report, but I
can provide a more sanitized excerpt if it would help.

What platform is your computer?

macOS / Darwin arm64

What is the issue?

I observed a codex exec resume <session-id> - --output-last-message <file> run
append a new turn to an existing Codex Desktop-originated session transcript, but
the Desktop session index did not update to the resumed turn time. The new turn
was also not reliably visible in Codex App immediately afterward.

The important part is that this did not look like model failure or data loss:
the transcript file received the user message and assistant response, and
--output-last-message captured the assistant response. The unclear part is the
Desktop/index visibility contract after the CLI resume.

Steps to reproduce

1. Start with an existing Codex Desktop session that has a recorded session id.
2. From a shell, run:

``bash
codex exec resume <session-id> - --output-last-message /tmp/codex-last-message.txt
``

with a short prompt on stdin.

1. Confirm that the corresponding ~/.codex/sessions/**/rollout-*<session-id>.jsonl

file receives:

• a new user message for the resume prompt;
• a new assistant response;
• a later file mtime matching the resumed turn.

1. Check the corresponding row in ~/.codex/session_index.jsonl.
2. Reopen or inspect the same session in Codex Desktop.

Expected behavior

One of these would be reasonable:

• codex exec resume updates the same durable session/index state that Codex

Desktop uses, so the resumed turn is visible in the App in a predictable way;

• or the CLI documents that codex exec resume is a transcript/CLI resume path

and does not guarantee Desktop UI/index refresh;

• or there is a supported command/API to refresh/reindex a session after CLI

resume.

Actual behavior observed

In one local repro:

• codex exec resume ... --output-last-message ... completed.
• The target session JSONL received the new turn and assistant response.
• The JSONL file mtime advanced to the resumed turn time.
• The session_index.jsonl row for the same session still had the older

updated_at.

• The resumed response was not visible in Codex App immediately afterward.
• Later, the App appeared to show the response, but I could not tell whether

that was due to a refresh, reload, or some other delayed readback.

So the practical issue is not "the resume failed"; it is that transcript
persistence and Desktop UI/index visibility appear to be separate states, and
the boundary is hard to reason about for tools that use codex exec resume as a
handoff mechanism.

Why this matters

This affects local automation and orchestration around Codex Desktop sessions.
If a tool sends a correction or handoff to an existing Desktop session through
codex exec resume, it needs to know whether the user will see that turn in
the App. Today the tool can prove that the transcript was updated, but not that
the Desktop session list/view was updated.

Related issues

Related, but not exact duplicates:

• #22796 covers Desktop sidebar/project history not showing local sessions.
• #23345 covers Codex App rendering failure after structured-output messages

produced by codex exec resume.

• #24016 covers promptless follow mode for codex exec resume.
• #25914 covers a broader app-server/Desktop active-thread discovery and

attachment contract.

This issue is specifically about the sync/visibility boundary after
codex exec resume appends to an existing Desktop-originated session.