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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

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

   execIssues related to the `codex exec` subcommandIssues related to the `codex exec` subcommand

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

   on Jun 15, 2026
2. github-actions commented on Jun 15, 2026

   

   github-actionsbot

   on Jun 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • bug: Local sessions persist in filesystem but disappear completely from codex resume --all and Desktop Sidebar (SQLite index mismatch) #28068

   Powered by Codex Action
3. bakemocho commented on Jun 15, 2026

   

   bakemocho

   on Jun 15, 2026

   Author

   More actions

   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.

   👍React with 👍1Reacted by Yi
4. bakemocho commented on Jun 18, 2026

   

   bakemocho

   on Jun 18, 2026 – with ChatGPT Codex Connector

   Author

   More actions

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

   

   Necmttn

   on Jun 21, 2026

   More actions

   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.

   👍React with 👍1Reacted by bakemocho
6. millionart commented on Aug 4, 2026

   

   millionart

   on Aug 4, 2026 – with ChatGPT Codex Connector

   Last edited by millionart

   More actions

   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>
      

   2. The command emitted thread.started with the exact requested session UUID.

   3. The rollout JSONL whose filename contains that UUID gained:

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

   4. The target Desktop/subagent conversation did not display the appended turn.

   5. 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.
7. boombx403-byte commented on Aug 18, 2026

   

   boombx403-byte

   on Aug 18, 2026

   More actions

   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.
8. bakemocho commented on Aug 18, 2026

   

   bakemocho

   on Aug 18, 2026

   Author

   More actions

   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.
9. JingYannn commented on Sep 20, 2026

   

   JingYannn

   on Sep 20, 2026 – with ChatGPT Codex Connector

   More actions

   Additional privacy-safe UX feedback from a Desktop + CLI workflow:

   The current boundary between Desktop-visible thread state, CLI resume state, local rollout persistence, and thread/session IDs is difficult for users to reason about. When recovery is needed, users may end up inspecting internal session files just to determine which thread they are resuming.

   A more explicit contract would help:

   • one stable logical thread ID across Desktop and CLI;
   • predictable visibility after CLI resume;
   • a supported refresh/reindex path;
   • visible thread ID / copy-ID action in Desktop and resume UI;
   • clear indication when Desktop and CLI are looking at different persisted/indexed states.

   No real thread IDs, paths, transcripts, project information, screenshots, or logs are included in this comment.