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

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

• #28068

Powered by Codex Action

Thanks for the duplicate suggestion. I reviewed #28068 and agree it is closely
related, but I do not think this report is an exact duplicate.

The shared theme is local session indexing/registration: session data can exist
on disk while the CLI/App index view does not reflect it reliably.

The difference in this report is the narrower codex exec resume path:

• the target was an existing Codex Desktop-originated session;
• codex exec resume <id> - --output-last-message <file> completed;
• the session JSONL received the new user turn and assistant response;
• --output-last-message captured the assistant response;
• the corresponding session_index.jsonl row still had the older updated_at;
• Desktop UI visibility was not immediate or deterministic.

So this is not primarily about recovering historical sessions from disk. It is
about whether codex exec resume should update the Desktop-visible session
index/UI, or whether the CLI should document that transcript persistence does
not guarantee Desktop UI/index refresh.

Additional observation: I narrowed this down further, and it no longer looks like only a stale session_index.jsonl.updated_at row.

The useful inspection checklist was:

1. Start from an existing Codex Desktop-originated session.
2. Run codex exec resume against that session so it appends a new turn to the existing transcript.
3. Confirm that the target transcript JSONL contains the appended user turn and assistant response.
4. Confirm that the matching session_index.jsonl row has an updated_at value at least as new as the latest transcript timestamp.
5. Confirm that the matching state_5.sqlite threads.updated_at_ms value is also at least as new as the latest transcript timestamp.
6. Reopen or focus the existing Desktop thread.

In my local test, steps 3-5 were all true, but the appended response still did not render in the existing Desktop UI thread.

I understand that manually editing local app state is not a supported workaround. I only used it, after making a backup, to narrow the diagnosis. This observation suggests the issue is not only a stale session_index.jsonl row; there may be another Desktop-side cache, readback, or transcript refresh boundary after codex exec resume writes to a Desktop-originated session.

codex exec resume should update the transcript and session index in the same lifecycle step.

After appending a turn, write an index event with session id, source transcript path, old/new updated_at, appended turn id, output file path if used, and origin exec-resume. Desktop can watch that event or rebuild from it instead of relying on a separate stale scan.

---

_Generated with ax._

Additional Windows/subagent-origin reproduction focused specifically on communication and execution identity.

Environment

• Windows 11 x64
• Codex Desktop package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Target session metadata:
• originator = Codex Desktop
• thread_source = subagent
• history_mode = legacy
• creating runtime cli_version = 0.146.0-alpha.9.2
• External global CLI used for the resume: codex-cli 0.142.0
• The successful external continuation ran with gpt-5.4; the Desktop target was using gpt-5.6-sol

The CLI/Desktop version and model mismatch is an important caveat and should itself have prevented treating the result as delivery to the active Desktop agent.

Observed behavior

1. A separate Codex Desktop conversation attempted to hand off a message by running:

``
codex exec resume <target-session-id> <handoff-prompt>
``

1. The command emitted thread.started with the exact requested session UUID.
2. The rollout JSONL whose filename contains that UUID gained:

• the new user message;
• an assistant response;
• a distinct new turn id;
• task_complete.

1. The target Desktop/subagent conversation did not display the appended turn.
2. The user later asked the visible target agent directly. It explicitly reported that it had not received the message and had not communicated with the sending conversation.

The target session ID was not mistyped and no different thread UUID was selected. Instead, codex exec resume created a separate CLI execution context from the saved transcript associated with that UUID. That continuation processed the prompt, while the original visible/live Desktop agent did not receive it.

Communication failure

This shows that a unique durable session UUID is not, by itself, a unique live-agent address:

• thread.started echoed the expected session UUID;
• the transcript recorded a completed continuation;
• but no mailbox or cross-thread delivery occurred;
• and the visible target agent remained unaware of the attempted communication.

A caller can therefore mistake “same session id + transcript append + task complete” for delivery to the intended live agent. The missing distinction is between:

1. resuming a saved conversation into a new execution context; and
2. sending a message to the currently active agent/branch associated with that conversation in Desktop.

This is related to the live-agent-vs-durable-thread distinction discussed in #32547, but here the failure is that an external continuation under the durable thread identity does not reach the visible target agent.

Safer expected behavior

At least one of these should hold:

• codex exec resume attaches to and reconciles with the Desktop-visible execution context before reporting success;
• or it explicitly reports that it created a detached/external continuation and that no live-agent/mailbox delivery occurred;
• or it fails closed for Desktop/subagent-origin sessions when no live attachment or branch lease can be established.

Machine-readable fields could include:

• operation kind: transcript continuation vs mailbox delivery;
• target source: Desktop/CLI/subagent;
• live-agent attachment status;
• target branch/turn identity;
• Desktop visibility/synchronization status.

Most importantly, a returned session UUID and a completed appended turn must not be usable as evidence that the intended live agent received a message.

Raw session IDs, local paths, project names, and conversation contents are intentionally omitted.

Hi @bakemocho, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.

Note for anyone else reading this thread before running the suggested command.

Some checkable facts about the comment above, all from public metadata:

• The commenting account was created on 2026-08-13, five days before the comment, and has no other public activity.
• It has posted the same templated comment — personalised with each reporter's handle and a paraphrase of their issue — to more than seventy issues in this repository. In one sample the posts land about three seconds apart, so this is automated.
• The pinned version 0.1.0a5 was published to PyPI at 11:49Z; this comment was posted at 12:02Z, roughly thirteen minutes later.
• The comment says "I've released", but the PyPI project is owned by a different account (shleder) than the one commenting.

I have not installed the package and I'm making no claim about what it does — it may well be a genuine tool being promoted badly. But pip install executes code from the package at install time, and this one is being pitched specifically to people whose session directories contain their own conversation transcripts, with a follow-up suggestion to share the output. Note also that reading the project's source repository would not settle the question, since the published wheel is a separate artifact from the repository.

If you want the diagnostic, get it deliberately rather than from an unsolicited comment: read the source, install a pinned version into a throwaway virtualenv, and don't paste raw output anywhere.