Repository navigation
[Windows App] read_thread returns only chatgpt-content-reference for completed ChatGPT replies #50329
Description
Activity
Additional reproduction and historical success comparison (2026-10-08)
I can reproduce the same issue on Codex Desktop for Windows, installed app version 26.1002.52244, build 13536, production channel. This is a report of observed tool outputs, not a claim about the root cause.
Current failing read (2026-10-08, ~13:07 UTC):
{ "threadId": "<redacted ChatGPT conversation ID>", "turnLimit": 10, "includeOutputs": true, "maxOutputCharsPerItem": 20000 }- The official
mcp__codex_app__read_threadcall returnsisError: false,schemaVersion: 1, and the correctthread.id/kind: "chatgpt". - The response contains two completed turns. Both
userMessagebodies are readable, but 2/2agentMessage.textvalues contain only::chatgpt-content-reference{index="…" source_message_id="…"}, with no assistant prose. source_message_idequals the corresponding assistant item ID.page.hasMore: falseandnextCursor: nulldo not establish body completeness.- A separate request using
maxOutputCharsPerItem: 120000was rejected with the documented<=20000validation error; this is not the body-read failure.
Historical working evidence (2026-10-05, retained original Codex tool logs):
- The same named native
mcp__codex_app__read_threadtool did successfully return full ChatGPTagentMessage.textbodies for another conversation: a ~6,316-character instruction and a ~10,505-character decision. - Successful calls used
maxOutputCharsPerItem: 20000,turnLimit: 1; bothincludeOutputs: falsewithouthostId, andincludeOutputs: truewithhostId: "local"were observed. - The historical session metadata shows
codex-cli 0.160.0; the historical Desktop App build is unknown. The successful and failing reads were not a controlled same-message comparison, so I cannot attribute the change to a particular app update, model, or parameter.
Expected: A supported, identity-preserving way for Codex's native ChatGPT thread reader to obtain the completed assistant's full text instead of an opaque content pointer.
Could maintainers clarify whether reference-only assistant bodies are intentional, whether
read_threadis expected to resolve them, and whether there is a supported first-party message-body retrieval/replacement interface? Please also clarify whether a fix is planned.No private conversation IDs, message IDs, user prompts/decisions, repository paths, or session logs are included here.
- The official
Additional reproduction on Linux, verified October 9, 2026.
Environment: Codex Desktop installed version
26.930.51102, build13100, production channel (prod). These installed-version fields were returned by the desktop'scheck_app_updatetool. Update availability was not checked remotely on Linux.Reproduction:
- Create a ChatGPT conversation and ask it to generate a random number.
- Reference that conversation in a Codex chat and ask for the generated number.
- Invoke the official desktop tool directly:
{ "threadId": "<redacted ChatGPT conversation ID>", "turnLimit": 10, "includeOutputs": true, "maxOutputCharsPerItem": 20000 }Observed: The call succeeds (
isError: false). It returnskind: "chatgpt", statusidle, two completed turns, and readable user messages. Both assistant messages contain onlychatgpt-content-referencedirectives. The original random-number response's returnedagentMessage.text, with its message ID redacted, is:::chatgpt-content-reference{index="0" source_message_id="<redacted assistant message ID>"}The
source_message_idmatches the corresponding assistant item ID. No number or assistant prose is present in that field. The caller could only obtain the intended number after the user supplied it directly; the referenced response body was not independently recovered.Repeating the read with
hostId: "local"produces the same result. Reading one turn at a time and following the returned cursor through the original response also returns only the directive. The full read ends withhasMore: falseandnextCursor: null.This reproduces the reference-only assistant-body behavior on Linux as well as the Windows reports above. It does not establish the root cause or first affected release.
Expected: Resolved assistant text, or a documented supported tool to retrieve the content behind
source_message_id.Private conversation/message IDs and local paths are omitted.
Additional reproduction on Windows on October 9, 2026, submitted with the affected user's explicit authorization.
- The official read_thread tool returns user messages in full, but completed assistant replies from ChatGPT-backed chats appear solely as
::chatgpt-content-reference{index="1" source_message_id="<redacted>"}. The owner can see the answer in the chat UI. - The owner moved the planning conversation to a new ChatGPT chat. Its owner-pasted handoff was readable, but its assistant reply again returned only the reference.
- A full computer restart did not repair retrieval.
- A read-only comparison with a second ChatGPT-backed chat reproduced the same reference-only assistant response. Codex-backed chat text was readable. This does not establish that all chats/accounts are affected.
- No supported reference-resolution tool was exposed to the calling execution chat. A private Page fallback has not been verified and is not claimed as a workaround.
Impact: a previously useful planner/executor workflow now requires the owner to manually copy complete assistant prompts, disrupting timing-sensitive diagnostic work.
Separate dispatch observation, not a proven common cause: a subsequent send_message_to_thread call returned success and its exact user message was visible on readback in the intended ChatGPT chat. At 23:12:58.111Z the desktop log recorded send success; at 23:13:15.308Z the ChatGPT conversation refetch completed with statusAfter=idle. No assistant response to that request was available in subsequent reads. This should not be conflated with the completed-reply body-loss bug.
Local logs also contain internal thread/read "thread not loaded" and unsupported placement errors for ChatGPT IDs. These may be fallback-routing probes; they are NOT established as the cause of either symptom.
No client package, settings, caches, credentials or session database was modified. Exact current app version was not independently verified for this follow-up. Private chat names, IDs, message contents, local paths and raw logs are omitted.
Please clarify the supported method for retrieving the actual completed assistant text, or fix the model-facing serialization to preserve it. The observations here independently reproduce the user-visible effect in #50329; the client-code mechanism in #52559 was not independently inspected in this session.
- The official read_thread tool returns user messages in full, but completed assistant replies from ChatGPT-backed chats appear solely as
Additional reproduction — October 10, 2026
Environment:
- Platform: Codex Desktop, Windows
- App version: 26.1007.21434
- Build: 13901
- Channel: prod
- Update status: up_to_date
Reproduction:
- Created a new ChatGPT conversation with the prompt: "Reply with TEST123 only."
- Confirmed the assistant's response was visible in the ChatGPT UI.
- Referenced the conversation in Codex.
- Inspected the returned
agentMessage.text. - Fully restarted Codex and repeated the test.
Actual result:
The tool returned only:
``
The actual assistant response ("TEST123") was unavailable.
Additional observations:
- The issue also affects multiple recent ChatGPT conversations.
- User messages are readable, but completed assistant replies frequently return reference-only content.
- Updating and restarting the application did not resolve the issue.
- The problem is reproducible even with a one-word assistant response, without tables or attachments.
Expected behavior:
The official conversation reader should return the actual assistant response or provide a supported mechanism to resolve the content reference.
Could maintainers confirm whether this is a known regression, whether a fix is planned, and whether any officially supported workaround exists?
This regression disrupts existing ChatGPT-to-Codex workflows that depend on reading completed assistant responses.
The desktop app has now confirmed that the in-app feedback was submitted for this report.
Feedback ID:
01a08fe4-ea36-7de1-9847-7ce652427401Please associate this feedback and its diagnostic information with issue #50329. The app's submission confirmation instructed us to include this ID in the existing issue.
This adds a diagnostic reference; it is not a new retrieval test or a claim that the problem has been fixed.
Additional controlled reproduction and message-format diagnosis (2026-10-11)
Submitted with the affected user's explicit authorization. Related mechanism report: #52559.
Direct native-tool observations
On Windows, the official
mcp__codex_app__read_threadwas called with:{ "threadId": "<redacted ChatGPT conversation ID>", "turnLimit": 10, "includeOutputs": true, "maxOutputCharsPerItem": 20000 }A controlled sample on October 9 included 6 ChatGPT conversations / 13 completed assistant replies:
Sample Replies Reference-only replies A 4 4 B 1 1 C 2 0 D 4 0 E 1 0 F 1 0 All 5 affected replies returned only a 95-character
::chatgpt-content-reference{index="…" source_message_id="…"}directive. The 8 controls returned readable bodies, including some with code blocks. Thus this is neither limited to one conversation nor triggered simply by the presence of code.Latest retest, October 11: A still returned 4/4 reference-only replies; B still returned 1/1; C still returned 2 readable replies (2,549 and 3,108 characters). Native calls succeeded; all three pages had
hasMore: false,nextCursor: null. A previous full app restart did not resolve the failure.Real-message format comparison
Read-only examination of the existing local cached responses for these exact six conversations found:
- All 5 affected assistant messages had non-null
metadata.model_dil_v2. - All 8 normal assistant messages lacked
model_dil_v2and legacy whole-message DIL metadata. - The affected messages still contained original text in
content.parts: 3,666; 8,124; 542; 6,969; and 97 characters. One affected reply had no code block. - These cached responses were used only to inspect the underlying format. Retrieving cached text is not counted as successful native
read_threadbehavior.
Inspected client conversion path
The package inspected on October 9 was
OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0; the then-reported desktop release was26.1002.52244, build13536, prod. These are historical inspected-version fields, not a claim that the current October 11 app version was reverified.In
webview/assets/app-initial-25361a10f2bf.js(minified names specific to this build):z8trecognizesmetadata.model_dil_v2and creates a whole-message rendering reference.R8tretains that reference incontentReferences, but replacesmarkdownwithUXt(referenceIndex, message.id), producing the directive.y7iexports the assistant as{role: r.role, text: r.markdown}, omitting the reference data and original text.- Consequently, model-facing reads receive the display directive rather than the completed assistant body.
This matches the mechanism described in #52559 and adds a comparison against actual affected/working message metadata.
Isolated branch validation and limits
The actual installed
y7i,R8t,z8t,UXt,a8t, andD8tfunctions were exercised in an isolated Node VM using the real cached messages; unrelated attachment/citation helpers were stubbed. Keeping each message ID and text unchanged:- Removing only
model_dil_v2from the 5 affected messages changed the result from a reference to their source text. - Adding synthetic
model_dil_v2to the 8 controls changed their result from text to a reference.
This validates the inspected conversion branch, not an end-to-end applied fix. No installed application package was modified, and no patch has been applied or verified in the running client.
Expected correction
Use a model-facing body extraction/resolution path for ChatGPT-backed reads rather than exporting display-only
markdown. Preserve usable original text or validated fallback Markdown; explicitly report unresolved structured content when neither is available. Please cover plain text, whole-message DIL, legacy DIL, inline citations, empty/invalid fallback, pagination and truncation, and rerun native reads on affected conversations.Private conversation titles, real conversation/message IDs, message bodies, user paths, credentials, raw cache files and full logs are omitted. Only sanitized diagnostic observations are submitted.
- All 5 affected assistant messages had non-null
What version of the Codex App are you using (From “About Codex” dialog)?
Windows MSIX package OpenAI.Codex 26.928.3736.0, verified on October 2, 2026 through
Get-AppxPackage. The runningChatGPT.exebelongs to that package. This is package/process-path evidence, not an About-dialog screenshot.What subscription do you have?
Signed in with a ChatGPT account; the exact subscription tier was not independently captured for this report.
What platform is your computer?
Windows 10 Home, version
10.0.19045(build19045); x64 application package.What issue are you seeing?
The official desktop
mcp__codex_app__read_threadcall succeeds for an existing ChatGPT conversation, but every returned assistant message contains only a::chatgpt-content-reference{...}directive inagentMessage.text. No actual assistant body is available to the calling agent.This is a body-availability / reference-resolution problem, not a missing tool, invocation failure, or observed crash.
Controlled read-only retest on October 2, 2026 (Asia/Shanghai):
kind: "chatgpt", with thread statusidle.agentMessageitems returned; all enclosing turns had statuscompleted.agentMessage.textvalues were strings of 95 characters consisting only of the directive.hasMore: falseandnextCursor: null.Sanitized excerpt of the actual result after unwrapping its JSON tool envelope (identifiers consistently redacted; unrelated fields and other turns omitted):
{ "thread": { "id": "<chatgpt-conversation-id>", "kind": "chatgpt", "status": { "type": "idle" } }, "page": { "order": "newest_first", "limit": 10, "nextCursor": null, "hasMore": false }, "turns": [ { "id": "<turn-id>", "status": "completed", "items": [ { "type": "agentMessage", "id": "<assistant-message-id>", "text": "::chatgpt-content-reference{index=\"1\" source_message_id=\"<assistant-message-id>\"}" } ] } ] }What steps can reproduce the bug?
On the affected Windows Desktop session:
mcp__codex_app__read_threadtool with the following arguments:{ "threadId": "<chatgpt-conversation-id>", "turnLimit": 10, "includeOutputs": true, "maxOutputCharsPerItem": 20000 }agentMessage.text, rather thanthread.previewor the user messages.This was reproduced on the existing affected conversation. We are not claiming that every account, conversation, or desktop build is affected.
What is the expected behavior?
A supported way for the calling agent to obtain the readable content of the referenced assistant message: either resolved text in the read result or a documented public resolver.
If reference-only or summary-only output is intentional, please clarify that contract and the supported way to retrieve the underlying message content. A successful read returning only an opaque reference is insufficient for a workflow that must inspect the actual answer.
Additional information
Historical comparison: A retained September 12, 2026 result for the same ChatGPT conversation and the same read parameters contains ordinary assistant text and stable message IDs. September 26 checks returned references, and the October 2 direct retest above still does. The exact first failing release/date is unknown; the earlier desktop package version was not independently established here.
Related external evidence, not a confirmed shared root cause: Another browser integration reported the identical directive while its ChatGPT tab displayed normal replies: chat-on-steroids #574. Its PR #579 uses a complete, resolved page capture for model-facing text readers; the change appears in v2.1.20. That is a separate browser-based path and does not establish how the official desktop tool should resolve the reference.
We have not completed a same-time browser/DOM comparison in our own environment. No private endpoints, content-reference dereferencing, browser cookies, or session-database edits were used in the direct test.
Questions for maintainers:
read_threadcontent resolution?read_threadsupport resolved assistant content for these messages? If so, what supported call or option should be used?source_message_id, or another supported first-party retrieval path?Existing issue #40300 concerns a ChatGPT-backed read causing a crash; this report concerns successful calls returning reference-only bodies.
Conversation titles, real conversation/message IDs, private message bodies, local paths, credentials, and full session logs are omitted. Codex assisted with the investigation and this report; the user explicitly authorized submission.