Android Remote cannot start turns in an idle large task: turn/start times out after 30s

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

• #37126

Powered by Codex Action

Additional reproduction on a newer Android build, with a slightly different input failure mode.

I currently have three or four long-running, highly active Codex threads that are effectively inaccessible on mobile:

• each affected thread starts to load but never fully loads into a usable state;
• the composer does not accept actionable input;
• I cannot send a new message, enqueue it, or steer the thread;
• there is no useful error or recovery state;
• new threads work normally, and some older threads also still work normally;
• fully closing and reopening the app has not helped.

This appears scoped to the largest/most active threads rather than being an account-wide, connectivity-wide, or general composer failure.

Environment:

• ChatGPT Android app: 1.2026.216
• Device: Google Pixel 7 Pro
• OS: Android 17
• Subscription: ChatGPT Pro
• Observed: 2026-08-13

Impact: the threads containing the most accumulated working context are precisely the ones that are locked out on mobile. Affected threads remain visible and selectable, but they cannot be loaded far enough to continue work or accept any form of input.

This corroborates the large-history hydration failure described here. In my case, the mobile UI does not reach the reported 30-second turn/start timeout because it never makes the composer usable enough to submit the turn. Loading a bounded recent tail independently of full-history hydration would likely prevent this failure mode.

Conversation titles, contents, account identifiers, and thread IDs are intentionally omitted. I can provide sanitized diagnostics or identifiers privately if maintainers request them.

Verified affected thread ID supplied by the reporter:

• 019fa4ea-80fe-79b3-afc0-689bb52f12ba
• 019fc246-0b10-75e2-acfe-d666c96cd246

Additional project-based threads show the same failure, but those surfaces do not expose thread IDs to the reporter. The two IDs above are representative examples rather than the complete affected set.

Today, it is unusable. I asked it to create a plan using Remote from Android, but I can't read the plan because the chat won't open. It was great until yesterday 👍

Today, it is unusable. I asked it to create a plan using Remote from Android, but I can't read the plan because the chat won't open. It was great until yesterday 👍

I ran another test today (2026-08-21). When using Codex Remote on Android, if I open a chat that already has a long conversation history, it still shows nothing and keeps loading indefinitely.

However, if I open that same chat in the ChatGPT desktop app on Windows and continue the conversation there, the Remote starts showing the conversation in progress, but it does not load any of the previous messages.

The same issue happens again once the current conversation is finished. If I leave the chat and open it again in the Remote, it stops showing the conversation and goes back to loading indefinitely.

Environment

• Mobile device: Android smartphone
• Android app: ChatGPT for Android 1.2026.223 (20), installed from Google Play
• Android connection during reproduction: Wi-Fi
• Desktop app: ChatGPT Desktop 26.818.3698.0 (unified ChatGPT/Codex app)
• Host: Acer Predator PHN16-72
• Operating system: Microsoft Windows 11 Home Single Language, 64-bit
• Windows version/build: 10.0.26200 (Build 26200)
• Processor: Intel Core i9-14900HX
• Memory: 31.7 GB RAM
• Graphics: NVIDIA GeForce RTX 4070 Laptop GPU and Intel UHD Graphics
• Observed: 2026-08-21

Additional reproduction on Fedora, without Codex Desktop in the path.

Environment:

• ChatGPT Android 1.2026.230 on Android 17
• Codex CLI/app-server 0.149.0 on Fedora
• standalone app-server started directly by a systemd user service with remote-control enabled
• affected thread uses paginated history

Observed:

• while a turn is active, Android can send and receive normally;
• once the turn becomes idle, the composer disappears after roughly one minute;
• reopening can restore it temporarily, but the older history remains missing;
• the host remains connected according to remoteControl/status/read, with no app-server restart and no Remote disconnect in the logs;
• Codex Desktop is not running and its import sync is disabled.

For the affected thread, local app-server measurements are fast: thread/turns/list summary returns 5 turns in about 5 ms (12.7 KB), while the full response is about 3.1 MB in 46 ms. The local thread/read path succeeds, so the data is present and this is not a 30-second host-side hydration delay in this reproduction.

I also disabled our one-minute local health probe and reproduced the disappearing composer again. That rules out the probe reconnecting the host. This looks like an Android Remote idle/hydration state problem, closely related to #36537 and the paginated-history regression in #37967.

I can reproduce the same large-history failure on Android 13, with one additional symptom: after I select a large existing task, Remote can show the header from another task and then fall back to the previously open task or to the task list.

Impact: New tasks and smaller existing tasks work normally, but I cannot reliably continue the tasks containing the most accumulated working context from my phone.

What happens

1. A smaller existing task opens with the correct header and conversation.
2. I return to the task list and select a larger existing task.
3. The selected conversation does not load. The header can change to another task.
4. Remote eventually falls back to the previously open task or the task list.
5. The selected task has occasionally appeared briefly while the host was producing live assistant or tool events. When that activity stopped, the wrong-header/fallback behavior returned.

Demonstrated history boundary

| Measurement | Working control | Smallest confirmed failure |
|---|---:|---:|
| Stored history records | 432 | 2,112 |
| History file size | 698,772 bytes | 4,433,838 bytes |
| Reconstructed turns / items | 4 / 40 | 11 / 224 |
| Default thread/resume size | 21,995 bytes | 482,949 bytes |
| Android result | Loads normally | Does not remain hydrated |

The same failure was also confirmed with tasks containing 2,433, 3,516, and 4,173 stored history records. The working and failing histories both had zero JSON errors, no image records, and nearly identical largest-record sizes (about 79.5 KB). This makes corrupted JSON, an image payload, or one unusually large record unlikely to be the required trigger.

Captured wrong-header/fallback sequence

| Point in the capture | What happened |
|---|---|
| Initial selection | Android sent thread/resume for the large task I selected. The host entered the normal reconstruction path for that task. |
| Host response | The requested histories reconstructed successfully with no parse, protocol, or app-server error. One 3,516-record response was prepared in about 126 ms; the 4,173-record attempt also emitted normal thread-status and token-usage events. |
| Connection state | The Remote connection remained established; there was no matching transport close or queue overflow. |
| 4 minutes 31 seconds later | At the point where the UI fell back, the same Android connection sent a second thread/resume for the previously open task. |

The final row is the key distinction: this is not only an incorrect title being painted over the selected task. Android first requests the intended task, then later requests a different task as the UI changes back.

Initial response comparison

The smallest failing history was tested only in an isolated Codex home; no live task or database was changed.

| Resume form | Returned history | Response size | Elapsed |
|---|---|---:|---:|
| Default | 11 turns / 224 items | 482,949 bytes | 249 ms |
| excludeTurns: true + 20-turn descending summary initialTurnsPage | 11-turn summary page | 38,827 bytes | 175 ms |

Both forms returned the correct task name, preview, update timestamp, and project ID with no parse or protocol error. The bounded form reduced the initial response by about 92%.

This reproduction shows that the failure does not require the 30-second host-side history delay from the original report: Android fails on a 4.43 MB history even when the correct response is prepared in well under one second. The measurements suggest retaining the selected task while Android reconciles a bounded recent page, then loading older history separately.

Environment and completed checks

• Samsung SM-G780G, Android 13
• ChatGPT for Android 1.2026.223, installed from Google Play with no update offered
• Windows Remote host package 26.818.3698.0
• Codex app-server 0.149.0
• Reproduced on both Wi-Fi and cellular
• Reproduced after force-stopping and clearing the Android app cache, restarting the host, and removing and recreating the Remote pairing
• Observed 2026-08-21

Task IDs, task titles, local paths, account details, credentials, raw logs, and conversation contents are omitted from this public comment.

Additional Windows + Android reproduction from 2026-08-21 that cleanly separates live turn delivery from persisted-history hydration.

Observed behavior

• Android Remote can now reach the Codex thread list.
• Very old, very small threads with almost no context open normally.
• Larger/long-running threads do not fully render. The screen stays effectively blank while the top of the UI flashes/loads indefinitely.
• While one of those large threads was still blank/loading, the user typed: Can you see this?
• Codex immediately replied: Yes, I can see your message.
• This proves the live turn path was active even though the existing transcript had not hydrated/rendered.
• The user then backed out of the thread and reopened it.
• On reopen, the newly completed Can you see this? exchange also did not appear; the thread again returned to the blank/loading state.

Why this seems useful diagnostically

This looks like a failure in persisted thread-history hydration/rendering rather than a dead thread or completely broken Remote transport:

1. The thread is selectable.
2. The composer can submit a new turn before old history has rendered.
3. The host receives the turn and Codex executes it.
4. The live response reaches Android.
5. After leaving and reopening, that same completed exchange is no longer visible because Android again cannot hydrate the persisted transcript.

Small-history threads opening successfully while large-history threads fail strengthens the correlation with thread size/history depth.

This user had a more severe Android→Windows Remote connection failure earlier in the day; that layer appears to have partially recovered. The current blocker is now specifically that important, long-running working threads remain unusable because their history cannot load, even though live turns can still execute.

Exact desktop/mobile build numbers were not captured for this reproduction. The Windows Codex desktop app had offered another update shortly before this test on 2026-08-21.

No conversation contents, account IDs, thread IDs, or other private project data are included.

Guys this is a serious ongoing bug, this issues renders the remote function in the mobile android app useless for long running tasks. I have a chat session where I create images and this happens, I have tried everything to resolve it - cleared the cache and storage of the app, uninstalled and reinstalled, unlinked and then relinked the phone to Codex still the issue persists.

I’m experiencing the same broader problem with Codex Remote on Android, and the current experience has become extremely frustrating.

My main workflow is to run Codex on my laptop and then use Remote from my phone to monitor the session and continue the conversation when needed. In practice, Remote is often very slow and unreliable:

• Sessions can take a very long time to load.
• The chat sometimes gets stuck on the loading screen and never opens properly.
• The UI frequently feels laggy or frozen.
• Moving between sessions or opening an existing conversation can be painfully slow.
• At times, the experience is so heavy and unresponsive that I end up avoiding Remote completely.

This is a major usability issue because the whole value of Remote is being able to quickly check and control an active Codex session away from the laptop. Right now, the performance and reliability make that workflow difficult to depend on.

I’d really appreciate it if Remote performance, session loading, and general responsiveness on Android could be treated as a priority. Even if full history takes time to hydrate, the UI should become usable quickly and allow the user to see recent activity and send a message without waiting for the entire session to load.

Immediate Windows workaround: check for duplicate app-server processes

If Android Remote is stuck loading, the composer disappears, or a simple message never starts, check whether Codex Desktop has spawned extra app-server processes:

Get-CimInstance Win32_Process -Filter "Name = 'codex.exe'" |
  Where-Object CommandLine -Match '(^|\s)app-server(\s|$)' |
  Select-Object ProcessId, ParentProcessId, CreationDate, CommandLine

If this shows two or more app-server processes with the same ChatGPT.exe parent and identical command lines, the older process may be a stale spare blocking Remote. Keep the newest successfully initialized process and terminate only the older duplicate(s):

Stop-Process -Id <OLDER_SPARE_PID>

Then confirm exactly one app-server remains and reopen the task on Android. This restored the previously inaccessible task within seconds for me.

Do not run the kill command if there is only one app-server. Do not terminate ChatGPT.exe, codex-code-mode-host, or the newest active app-server. Killing the sole app-server left Codex unable to start until Windows was rebooted.

---

Why this happens and how to distinguish it from history hydration

I found a separate local app-server lifecycle failure that can produce the same Android symptoms: the host appears connected, but a task loads forever, the composer disappears, or turn/start never reaches the usable Desktop connection.

On Windows, this read-only check shows the local app-server children:

Get-CimInstance Win32_Process -Filter "Name = 'codex.exe'" |
  Where-Object CommandLine -Match '(^|\s)app-server(\s|$)' |
  Select-Object ProcessId, ParentProcessId, CreationDate, CommandLine

Interpretation:

• Zero or one app-server: do not terminate it. This workaround does not apply.
• Multiple app-servers with different parents/commands: do not guess; this workaround does not safely apply.
• Multiple app-servers with the same ChatGPT.exe parent and identical command lines: Desktop may have leaked an older child during initialize-timeout/restart recovery.

In the confirmed duplicate case, the successful mitigation was:

1. Identify the newest process that the matching Desktop log shows completed initialization successfully.
2. Keep that process.
3. Terminate only the older sibling(s) proven to be earlier spawns from the same Desktop log.
4. Verify exactly one app-server remains and Desktop is still responsive.
5. Reopen the task on Android.

That restored Android hydration within seconds for me.

Critical warning: do not kill the sole app-server, and do not choose solely by age or CPU usage. I tested terminating the only app-server; Codex then would not start again until Windows was rebooted. I am intentionally not including a blind Stop-Process command.

This is not a general fix for the large-history hydration bug in this issue. If only one healthy app-server exists, the original thread/turns/list / Android hydration problem remains. It is a diagnostic branch for a second Windows failure that presents similarly.

The log-confirmed lifecycle race and successful duplicate-only mitigation are documented in #39954, comment 5407302155. I now use a local per-user guard five minutes after Codex launch; it no-ops unless the Desktop log positively identifies the newest initialized keeper and every older duplicate spawn.

Hello it is human Eli

Hopefully the comment above fed to your own codex instance can help some of you experiencing this problem. It helped me!

🙂

I now get codex to run a check five minutes after the desktop app starts to check for duplicate app server processes and to kill them.

Hopefully OpenAI will fix this issue so it's not needed in the future, but for now this helps me!