[Windows Desktop] Codex and Local Work lose ChatGPT conversation reader while Cloud Work retains partial semantic access

What version of the Codex App are you using?

• Desktop app build shown by the app: 26.908.40834
• Windows package: OpenAI.Codex_26.908.4834.0_x64__2p2nqsd0c76g0

What platform is your computer?

Windows x64.

What issue are you seeing?

Full ChatGPT conversation access that previously worked from Codex is no longer available. The regression affects both existing and newly created Codex tasks. Local Work also has no ChatGPT conversation reader, while Cloud Work can still retrieve fragments from the same existing conversations through distinctive body-text / semantic anchors.

This comparison indicates that the conversations still exist, but the complete conversation-reader capability is not consistently provisioned across Codex and Work surfaces.

Codex

The model-visible registry may still describe app tools such as:

• codex_app__list_threads
• codex_app__read_thread
• codex_app__send_message_to_thread

However, calling list_threads, read_thread, or list_projects through that dynamic surface returns:

This app tool is no longer available through dynamic tools. Use the codex_app MCP server. If that server is unavailable on this host, task delegation is unavailable.

An older invocation path also fails because the function no longer exists:

TypeError: tools.mcp__codex_app__read_thread is not a function

No callable mcp__codex_app__* replacement for these thread/chat operations is exposed to the task.

Local Work

• Starts and reads authorized local project files normally.
• Can read the local mirror of a ChatGPT Project.
• The mirror contains project files/uploads/generated documents, but no usable ChatGPT conversation transcript index.
• No ChatGPT conversation list/read capability is exposed.

Cloud Work

• Can find fragments of the same existing ChatGPT conversations using distinctive body-text / semantic anchors.
• Title-based lookup is unreliable.
• It cannot reliably reconstruct the complete conversation in original message order.

This behaves like partial server-side semantic retrieval rather than the previous complete conversation reader.

Relevant diagnostic evidence

Sanitized desktop log sequence:

mcp_server_startup_status_updated server=codex_apps status=ready
dynamic_app_tool_server_request_received tool=list_threads
Sending server response success=false tool=list_threads
dynamic_app_tool_server_request_received tool=read_thread
Sending server response success=false tool=read_thread

The official codex_apps server and local app-server functionality are otherwise operational. Local files, terminal commands, and ordinary Codex tasks work.

No conversation contents, conversation IDs, private paths, session transcripts, credentials, or raw logs are included in this report.

Steps to reproduce

1. Open the Windows desktop app and create a new Codex task.
2. Ask the task to list ChatGPT conversations or read a known existing ChatGPT conversation.
3. Inspect the available tool registry.
4. If the dynamic codex_app__list_threads / codex_app__read_thread definitions are present, call them.
5. Observe that the dynamic handler rejects the call and directs the caller to a codex_app MCP replacement that is not exposed.
6. Create a Local Work task and repeat the ChatGPT conversation-read request; no conversation reader is available.
7. Create a Cloud Work task and search the same existing conversation using a distinctive body-text anchor; fragments may still be returned, but complete ordered reading is unavailable.

Reproduced on existing and newly created tasks. Restarting the desktop app did not restore the capability.

Expected behavior

If reading ChatGPT conversations from Codex / Local Work remains supported, these surfaces should receive a consistent first-party conversation reader or a documented MCP replacement.

If the capability has intentionally moved or is now restricted to another surface, the UI and documentation should state that boundary instead of exposing stale dynamic definitions that direct callers to an unavailable replacement.

Related public reports

• #40300 — ChatGPT conversation recognized as kind: "chatgpt", but read_thread is routed to local app-server thread/read
• #35410 — controlled evidence that first-party read_thread could read a ChatGPT conversation directly
• #44044 — thread-management tools disappear from the model-visible registry while persisted data remains backend-readable
• #40865 — dynamic tools disabled in favor of a missing codex_app MCP replacement
• #40852 — partial thread-tool surface after migration
• #33637 — tool availability changes with model routing

Questions

1. Is full ChatGPT conversation reading from Codex still intended to be supported?
2. Has the old dynamic read_thread path been migrated to a codex_app MCP capability?
3. Is the missing replacement on Codex / Local Work a known routing or provisioning regression?
4. Is there a supported temporary way to retrieve a complete, ordered ChatGPT conversation without manually exporting or pasting it?

Start with the sanitized desktop log sequence and compare the behavior described in related reports #40300, #35410, #44044, #40865, and #40852. Determine whether full conversation reading is still supported and whether a codex_app MCP replacement is provisioned; the issue is resolved when the surfaces provide a consistent reader or clearly document the supported boundary.