[Windows → iPhone Remote] History pagination times out and latest messages are missing; thread/items/list returns large image generation records #54751

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   iOSIssues related to the Codex iOS appIssues related to the Codex iOS app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   remote

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Oct 17, 2026
2. github-actions

   changed the title [-][Windows → iPhone Remote] 历史分页加载超时、最新消息缺失；thread/items/list 返回大块图片生成记录[/-] [+][Windows → iPhone Remote] History pagination times out and latest messages are missing; thread/items/list returns large image generation records[/+] on Oct 17, 2026
3. github-actions commented on Oct 17, 2026

   

   github-actionsBot

   on Oct 17, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation:

   Versions used

   • Windows desktop app internal build: 26.1013.31256 (from the installed app and startup records).
   • Windows installer version: 26.1013.3656.0.
   • Backend bundled with the app: codex-cli 0.163.0-alpha.10.2.
   • Phone: iPhone, using Codex Remote in ChatGPT; the specific iOS and mobile app versions have not yet been collected.
   • Subscription type: not collected during this investigation.

   Platform and network environment

   • Windows 11 x64; the system reports Microsoft Windows NT 10.0.26200.0.
   • Both the desktop and phone access the service through a proxy/VPN. The desktop backend explicitly configures HTTP_PROXY and HTTPS_PROXY to point to a local HTTP proxy.
   • The explicit proxy allows the desktop to come online. With this configuration retained, the phone can connect to the host and open a control conversation, but two other conversations containing generated images still cannot load completely.
   • This report focuses on history loading failures after the host comes online. The proxy's impact on large data transfers has not yet been ruled out.

   Actual behavior

   The following was repeatedly observed in two existing conversations on 2026-10-16 (UTC+08:00):

   1. The Windows desktop can open the conversations normally and display the latest completed replies.
   2. iPhone Remote can see the host and conversations, but opening these two conversations times out.
   3. After force-closing and reopening the mobile app, one conversation can display a small amount of old execution progress while still reporting a timeout. It is not possible to browse far enough back through the history, and the latest replies completed on the desktop have not synced to the phone.
   4. Meanwhile, a readable control conversation can still be opened on the same phone.
   5. The user also observed that attempting to open a larger conversation may cause the host to go offline, then come back online after approximately 5–10 minutes. This duration is a user observation and has not yet been precisely correlated with host logs for each occurrence; it should not be treated as a fixed protocol timeout or confirmed causality.

   The exact full error message on the phone has not yet been collected. “Timeout” in this report is the user's description of the behavior.

   Steps to reproduce

   1. On the Windows desktop, prepare an existing conversation with a history containing multiple image generations and tool calls.
   2. Confirm that the conversation can be read locally on the desktop and already has a latest completed reply.
   3. Connect to this host using a paired iPhone Remote and open the conversation.
   4. Observe history loading timeouts, only old fragments being displayed, or missing latest replies on the phone; then open a control conversation for comparison.

   These steps reproduce the issue in the two existing conversations. There is not yet a minimal synthetic conversation that can be shared publicly, nor has a definite size threshold been established.

   Expected behavior

   The phone should promptly display the latest text and completion status and allow continued use of the original conversation, loading older messages and images on demand. A single large history page should not make other conversations or the entire remote connection unavailable for an extended period. An application-level fix is desired, rather than having to keep creating new conversations, transfer summaries, or clear history to use Remote.

   Stage confirmed by host logs

   In three connection samples from 23:08–23:13 on 2026-10-16 (UTC+08:00), the host received the following sequence:

   initialize → thread/resume → thread/turns/list → thread/items/list
   

   Each sample contains 3 thread/turns/list requests and 15–16 thread/items/list requests. When the phone reconnects, it resumes both affected conversations and the control conversation simultaneously, so these requests cannot be treated as strictly single-conversation tests.

   These logs confirm that history pagination has begun. They do not record the full parameters of each pagination request, actual completion of response transmission, or reception on the phone, so individual requests cannot be mapped precisely to specific pages in the table below. No fs/readFile or Remote pong timeout was captured in this window; this does not mean such events were absent throughout the entire failure period.

   Measurements using isolated copies with the same backend version

   To avoid mistaking on-disk history file size for transfer volume, the same installed backend was used with an independent temporary CODEX_HOME, containing copies of the tested conversations' history and paginated display projections. The APIs were called using the codex_chatgpt_ios_remote client identity:

   1. Call thread/turns/list with itemsView: "summary" to retrieve turns.
   2. Call thread/items/list for each turn, omitting limit to use the default of 25 items per page.
   3. Follow nextCursor through the final page, measuring only JSON RPC response bytes, elapsed time, and item types.

   Isolated copy	Pages	Total bytes across all paginated responses	Largest page (bytes)	Local RPC time for largest page	Total bytes for imageGeneration items
   Affected conversation A	19	15,344,422	10,039,273	0.069 seconds	14,497,682 (6 items)
   Affected conversation B	22	7,687,304	4,467,941	0.034 seconds	6,492,954 (3 items)
   Control conversation that opens on the phone	33	1,295,915	150,630	0.003 seconds	0

   All paginated reads successfully reached the final page, with no API errors. These are byte counts of local, uncompressed JSON RPC responses, not actual bytes received by the phone, network packet capture volume, or phone memory usage. The control conversation continues to have new activity; the measurements reflect its snapshot at the time.

   Simulating the removal of imageGeneration items only in in-memory copies of the responses reduced the total pagination volume to approximately 0.85 MB for conversation A and approximately 1.19 MB for conversation B. This simulation demonstrates that these items account for most of the data volume; it was not applied to the actual conversations and is not evidence of a successful fix on the phone.

   Relevant source code clues

   Based on rust-v0.163.0-alpha.10.2:

   • thread_resume_redaction.rs: omits imageGeneration from thread/resume for iOS/Android Remote and trims MCP data.
   • thread_items_list_response_inner: thread/items/list reads and converts complete stored items without invoking the mobile response trimming logic above.
   • Pagination count constants: 25 items by default, with a maximum of 100; this path paginates by item count without a corresponding response byte budget.

   As a result, the large image generation records omitted during the initial resume reappear in subsequent paginated reads. The isolated measurements above reproduced this difference in data volume.

   Areas for investigation and limits of the conclusions

   The strongest current hypothesis is that subsequent large pages trigger timeouts during remote transfer or processing on the phone. It is not yet possible to identify network speed, the proxy, phone decoding/rendering, or server-side queuing as the ultimate bottleneck, nor to assert that the phone has received these large pages in full.

   Please investigate:

   1. Whether mobile thread/resume and thread/items/list should use a consistent lightweight response strategy while preserving correct pagination cursor and item semantics.
   2. Whether image data can be read on demand, and whether pagination needs limits based on bytes rather than only item count.
   3. Whether large responses for a single conversation, retries, and heartbeat/recovery on the shared Remote channel affect one another.
   4. Whether a supported diagnostic method can be provided to record response size, transmission completion, phone reception/decoding results, and the stage at which a timeout occurs for each request, so that causality can be verified.

   Related reports

   Related, but not proven to share the same root cause: #50934 (large histories affecting Remote), #47148 (conversations with many images failing to load on mobile), and #40249 (image generation results returning large amounts of data through history read APIs). This report adds evidence from the Windows→iPhone history pagination stage and same-version measurements showing inconsistent response trimming between thread/resume and thread/items/list.

   Privacy and scope of operations

   This report is submitted with the user's authorization. Public content includes only anonymized measurements, versions, necessary network context, and public source code links; raw chats, images, databases, accounts, device/conversation identifiers, and private file paths remain on the local machine. Diagnostics used independent copies, and the original history remains intact.
4. parangsori commented on Oct 20, 2026

   

   parangsori

   on Oct 20, 2026

   More actions

   Additional macOS-to-mobile case: newest replies remain visible, but earlier history persistently times out in one image-heavy chat. Adding this here rather than opening a duplicate. The same root cause is not yet established.

   Observed behavior and reproduction

   1. Continue an existing desktop Codex chat containing many image/tool outputs.
   2. Open that same chat on mobile and load earlier messages.
   3. In this case, the user reports that new replies are visible, but messages after an afternoon 15:41 boundary cannot be loaded and a message-loading/timeout error persists. Other chats eventually load on the same mobile client. This affected chat is relatively recent.
   4. Return to the Mac: saved text replies are still readable locally. The mobile failure remains unresolved.

   The mobile observations above are user-reported, not an independently captured mobile trace. The report was collected on October 20–21, 2026 (Asia/Seoul). The exact date of the reported 15:41 boundary, mobile OS/app version, and full mobile error text were not collected. No public minimal synthetic reproduction or deterministic size threshold is available.

   Local evidence

   Read-only streaming inspection of one local rollout snapshot found:

   Measurement	Observed value
   JSONL file size	512,968,654 bytes
   Largest individual JSONL record	34,832,478 bytes
   Inline data:image/...;base64, markers	161 (marker count, not a unique-image count)

   The largest record occurred later than the reported 15:41 boundary; it has not been identified as the item failing on mobile. These are on-disk storage measurements, not measured RPC response sizes, mobile transfer volumes, or mobile memory usage.

   A separate desktop read_thread diagnostic tool produced the following results for this chat, with includeOutputs: false and maxOutputCharsPerItem: 500:

   • turnLimit: 1: success; following the returned opaque cursor for another one-turn page also succeeded.
   • turnLimit: 10: Thread history exceeds the read size limit. Try fewer turns. A single oversized turn cannot be read by this tool.

   This is the diagnostic tool's guard message, not the phone's error, and it does not prove that mobile uses the same failing path. A bounded desktop-log sample also contained successfully routed thread/read, thread/turns/list, and thread/items/list responses. No request-level mobile receive/decode timing was captured. Recovering seven completed text replies locally succeeded; this does not certify every stored record or fix mobile access.

   Environment and source comparison

   • Host: macOS on Apple silicon. Installed desktop bundle version: 26.730.61309 (bundle metadata; not confirmed as the active process version).
   • Shell CLI reports codex-cli 0.160.0; the desktop-bundled backend version was not established.
   • Installed OMO plugin: 5.1.38. This is not a clean-plugin-free reproduction.
   • Fresh source comparison: LazyCodex bca7c59b870b1d468e7d2ea869ef263661a2c8d8 and upstream Codex aa081afb1b044ee66c738b8808c07f13dfcff373. The inspected LazyCodex snapshot did not contain an implementation of the mobile history reader or the diagnostic guard string. Reporting here also follows the official Codex issue-reporting guidance.
   • In the latest upstream snapshot, mobile resume redaction trims MCP payloads and removes image-generation entries, whereas the items-list path pages stored items by count and converts them to entries without invoking that redaction function. This supports investigating the boundary already discussed here; it does not establish which code version or stage caused this user's mobile timeout.

   Requested investigation

   Please check whether the mobile pagination path can keep recent text accessible and load large image/tool payloads on demand, with byte-aware response budgets and request-correlated transfer/decode timing. A regression case should cover a recent image-heavy chat where new replies work while older pages repeatedly fail, alongside a normally loading control chat.

   No original chats, images, account/device/thread identifiers, private file paths, or credentials are attached. The original conversation and settings were not rewritten, cleared, or restarted during this diagnosis.

   ---

   This issue or PR was generated by LazyCodex.
   Tag: lazycodex-generated