[Data-loss bug] Selected-text sidebar creates orphan Codex threads that silently disappear after restart

[michaelrenyu2019]

[Data-loss bug] Selected-text sidebar creates orphan Codex threads that silently disappear after restart

Severity

High — data-loss-class persistence defect.

This is not a cosmetic sidebar issue, not an archive/filter issue, and not user confusion. A Selected-text sidebar conversation can accept multiple turns, run Codex tools, modify local/global files, and appear fully functional, while never being registered in the local thread catalog and never receiving a rollout/session transcript. Restarting Codex then makes the conversation impossible to reopen.

The current UX gives no warning that the conversation is non-persistent. Allowing a seemingly normal Codex thread to perform consequential tool calls while silently failing to persist its transcript is unacceptable behavior for a developer tool.

Environment

• macOS
• Codex Desktop: 26.715.72359
• Desktop build: 5718
• Bundle: com.openai.codex
• Embedded Codex core: 0.145.0-alpha.30
• Originator reported by session metadata: Codex Desktop
• Source reported by session metadata: vscode
• Local workspace mode
• Custom model provider; persistence is local and the failure occurs in Codex thread/session storage, not model generation

Reproduced twice

Orphan thread 1

• Thread ID: 019f8d71-e9f0-7b10-b7b9-5c0e3b08d298
• Runtime: 2026-07-23 13:28:02–13:46:17 (Asia/Shanghai)
• Log rows tied to thread: 278
• First message used Selected-text payload
• Thread accepted multiple turns and executed tools
• state_5.sqlite: no thread row
• ~/.codex/sessions: no rollout file
• ~/.codex/archived_sessions: no archived rollout
• logs_2.sqlite: full execution trace remains
• Result after restart: thread disappeared and could not be reopened

Orphan thread 2

• Thread ID: 019f8de5-d04a-7bb1-ab86-65423805c52d
• Runtime: 2026-07-23 15:34:37–15:45:12 (Asia/Shanghai)
• Log rows tied to thread: 149
• First message payload:

# Selected text:

## Selection 1
代理主动执行

## My request for Codex:
代理指的是你codex吗

• Follow-up turns were accepted
• Codex requested and received approval to modify global ~/.codex/AGENTS.md
• The file modification and timestamped backup succeeded
• state_5.sqlite: no thread row
• ~/.codex/sessions: no rollout file
• ~/.codex/archived_sessions: no archived rollout
• logs_2.sqlite: execution trace remains
• Result after restart: thread disappeared and could not be reopened

Normal control thread

A normal project Codex thread created during the same period persisted correctly:

• Thread ID: 019f8d85-4de1-7370-b06f-6280abe77fc9
• Present in state_5.sqlite
• Rollout exists and continues updating:

~/.codex/sessions/2026/07/23/
rollout-2026-07-23T13-49-11-019f8d85-4de1-7370-b06f-6280abe77fc9.jsonl

This control demonstrates that the database, sessions directory, and general persistence path were functional. The defect is strongly associated with the Selected-text/sidebar thread creation path.

Reproduction steps

1. Open a local Codex project in Codex Desktop.
2. Select a text range in the project/file UI.
3. Start a sidebar conversation using the Selected-text/Selection context entry point.
4. Continue for multiple turns.
5. Allow Codex to run a harmless tool call or create/modify a test file.
6. Observe that the conversation behaves like a normal Codex thread.
7. Before restarting, query the local thread catalog and session directory.
8. Quit Codex completely and reopen it.
9. Search Chats, use Chronological filtering, check Archived chats, and return to the same project.

Actual result

• Codex assigns a real thread ID.
• The in-memory thread accepts turns and tool calls.
• Operational logs are written to logs_2.sqlite.
• No corresponding row is created in state_5.sqlite.
• No rollout/session transcript is created.
• The UI provides no ephemeral/non-persistent warning.
• Restart clears the in-memory thread.
• The conversation cannot be searched, resumed, unarchived, or reopened.
• Tool side effects remain on disk, but the explanation, decisions, approvals, and transcript disappear from the product UI.

Expected result

The official IDE command is documented as:

chatgpt.addToThread — Add selected text range as context for the current chat

Therefore one of the following must happen:

1. The selected text is added to the current, already-persisted Codex chat; or
2. A new standard Codex thread is created, immediately registered in the thread catalog, and assigned a rollout/session transcript.

If the product intentionally creates an ephemeral thread, it must:

• say so explicitly before the first message;
• clearly label the thread as non-persistent;
• warn that restart/close will discard it;
• provide a one-click “Move to Codex task” action;
• not allow consequential tool calls or file modifications without first creating a durable transcript.

Silently presenting an ephemeral thread as a normal Codex conversation is not an acceptable design.

Local evidence queries

Thread lookup returned zero rows for both orphan IDs:

SELECT id, title, rollout_path
FROM threads
WHERE id IN (
  '019f8d71-e9f0-7b10-b7b9-5c0e3b08d298',
  '019f8de5-d04a-7bb1-ab86-65423805c52d'
);

Relevant session lookup returned no files:

find ~/.codex/sessions ~/.codex/archived_sessions \
  -name '*019f8d71-e9f0-7b10-b7b9-5c0e3b08d298*' \
  -o -name '*019f8de5-d04a-7bb1-ab86-65423805c52d*'

The same IDs have substantial rows in logs_2.sqlite, proving that these were real executing Codex threads rather than unsent composer drafts.

Why this requires product and design ownership

This defect crosses implementation and UX boundaries:

1. Thread lifecycle: a runnable thread is created but not registered.
2. Persistence: rollout initialization does not occur.
3. Tool safety: irreversible or consequential side effects may outlive the missing transcript.
4. UX honesty: the product does not disclose that the conversation may be ephemeral.
5. Recovery: no built-in migration or recovery path is offered after restart.

Please do not close this as “check Archived chats,” “use Chronological filtering,” or “Quick Chat is not shown in the Codex sidebar.” Both orphan threads had Codex thread IDs, local workspaces, Codex tool execution, and Codex approval flows. They were not merely ordinary ChatGPT drafts.

Requested fix / acceptance criteria

• Selected-text context is added to the current persisted thread by default.
• If a new Codex thread is created, catalog registration and rollout creation complete before tool execution is allowed.
• Failure to initialize persistence is surfaced as a blocking error, not silently ignored.
• The UI visibly distinguishes standard, Quick Chat, and ephemeral sidebar conversations.
• Ephemeral conversations provide “Move to persistent Codex task.”
• Restart/reopen integration tests cover Selected-text threads.
• Tool side effects and transcript persistence are treated transactionally enough that a user is never left with changed files but no recoverable conversation.
• Product/design documentation clearly states the persistence behavior of every sidebar entry point.

Maintainer response requested

A maintainer response is explicitly requested. Please provide all of the following rather than silently closing, auto-locking, or redirecting this report without an explanation:

1. Confirm whether the Selected-text/sidebar thread is intended to be persistent, Quick Chat, or ephemeral.
2. Confirm whether the two orphan thread patterns described above can be reproduced.
3. State which component owns the defect: Desktop UI, IDE-context bridge, app-server thread registration, rollout initialization, or another layer.
4. Provide the current handling status and, when available, the release/build containing the fix.
5. If the behavior is considered intentional, provide the product rationale and point to the exact user-facing warning/documentation that explains the data-loss risk before tool execution.
6. When closing the issue, include a concrete resolution note: fixed, duplicate with linked tracking issue, cannot reproduce with requested diagnostics, or intentional behavior with documentation.

Please do not close this report with a generic “check Archived chats,” “use Chronological filtering,” or “works as designed” response that does not address the missing catalog rows and missing rollout files. The reporter needs a clear explanation of what happened and how the product team is handling it.

Privacy and logs

Full logs_2.sqlite is not attached because it may contain unrelated sensitive data. Thread-scoped, time-bounded, redacted evidence can be provided privately to OpenAI upon request.

Bottom line

This is a reproducible data-loss-class defect in a basic workflow. The product currently lets users trust a conversation, approve tool actions, and modify files without ensuring that the conversation itself is durable. The Selected-text/sidebar flow needs an explicit persistence contract and enforcement, not another undocumented edge case pushed onto users to discover after restart.

[github-actions]

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

• Codex Desktop chats disappear from sidebar after restart when the first request is supplied as a pasted-text attachment #34446

Powered by Codex Action