[Android -> macOS] Existing tasks stay on gray skeleton across two Android devices while a new Android-created task works
What issue are you seeing?
ChatGPT Android Remote connects to a macOS Codex host and displays the host, project, and task list. The selected host shows a green connected indicator. However, opening an existing desktop task leaves the conversation body on gray skeleton placeholders indefinitely.
The same existing tasks open and run normally in ChatGPT/Codex Desktop. On the primary Android phone, a prompt sent into an affected task still reached the Mac and executed, but neither existing history nor the new response hydrated on Android.
A brand-new task created from Android on the same host/worktree opens and updates normally.
The existing-task failure was then reproduced on a second Android device after a fresh sign-in and new Remote connection. This rules out a stale cache, pairing state, or device-specific keys on only the original phone.
As an additional platform control, the same existing task opens normally through Codex Remote on an iPad connected to the same Mac host. With the host, account, and persisted task held constant, the current discriminator is the client platform: iPad works while two Android devices fail. This narrows the problem to the Android Remote path rather than the Mac host or the stored task data.
Environment
- Host: Apple M4 Mac mini
- macOS:
26.5.2(25F84) - Active unified ChatGPT/Codex Desktop:
26.818.22352(bundle build6872) - Android device A: primary Samsung Galaxy Ultra phone (exact model/build not independently captured)
- Android device B:
SM-F721N, Android16(SDK 36) - ChatGPT on device B:
1.2026.223 - Control client: iPad (exact model/app build not yet captured)
Controlled observations
| Surface | Task type | Result |
| --- | --- | --- |
| macOS Desktop | Existing task | Opens and runs normally |
| iPad Remote | Same existing task | Opens normally |
| Android device A | Existing task | Green host connection, then indefinite gray skeleton |
| Android device A | New task created from Android | Opens and updates normally |
| Android device B, fresh sign-in/connection | Same existing task | Green host connection, then indefinite gray skeleton |
This reproduced on multiple recent existing tasks, including tasks only about 20-50 minutes old. It is therefore not limited to very old or inactive history.
What steps can reproduce the bug?
- Run ChatGPT/Codex Desktop on macOS with Remote enabled.
- Open an existing task on Desktop and confirm its history renders normally.
- On ChatGPT Android, select the same Mac host and project.
- Confirm that the host shows a green connected indicator and that the task list loads.
- Open the existing task.
- Observe that the conversation body remains on gray skeleton placeholders indefinitely.
- Create a new task from Android on the same host/worktree.
- Observe that the new Android-created task opens and updates normally.
- Sign in and connect a second Android device to the same host.
- Open the same existing task and observe the same indefinite gray skeleton.
- Open the same existing task through Remote on an iPad connected to the same Mac host.
- Observe that the task opens normally on iPad.
Troubleshooting already completed:
- force-stopped and restarted ChatGPT Android;
- fully restarted ChatGPT/Codex Desktop;
- rebooted one Mac host;
- tested with Tailscale disconnected;
- opened the affected task on Desktop before retrying on Android;
- retried multiple recent tasks;
- reproduced with a freshly connected second Android device;
- opened the same existing task successfully through iPad Remote.
What is the expected behavior?
Any task shown in Android Remote should hydrate its message history and render new responses, regardless of whether it was created on Desktop or Android and regardless of which freshly paired Android device opens it. Android should behave consistently with iPad Remote when opening the same task on the same host.
Additional information
The observable split is:
- host discovery / pairing / task list: working;
- Android -> Mac send path on the primary device: working;
- existing-task history and response hydration on Android: not working;
- new Android-created task: working;
- iPad Remote rendering of the same existing task: working;
- Desktop rendering of the same existing tasks: working.
The iPad control provides a direct cross-client comparison: same account, Mac host, and existing task; iPad renders it while two Android devices do not. A server component may still branch by client platform, but the failure is isolated to the Android Remote path rather than Remote generally.
A secondary symptom is that Android can intermittently show another Mac host as red/offline even while that Mac remains locally reachable and Desktop works normally. This may be a related Remote presence/control-plane symptom, but it is not required for the existing-task hydration reproduction above.
This report is intentionally separate from:
- #39845: similar user-visible A/B result, but that report is Windows-specific; this report is macOS and reproduces across two Android devices, with iPad working as a control.
- #39908: the Android client disconnects before a usable session; here the host stays green, the task list loads, and new Android-created tasks work.
- #39860: failure occurs while loading the task directory; here the directory loads and failure begins after selecting an existing task.
- #38653: large paginated histories can exceed hydration budgets; here some affected tasks were recent, so task age alone does not explain the failure.
No task IDs, account IDs, environment IDs, hostnames, private paths, prompts, or credentials are included. A screenshot of the second-device gray-skeleton state was captured locally for verification but is not uploaded publicly.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I reviewed #39845. The user-visible symptom is closely related, but this report adds a macOS host reproduction across two independently connected Android devices, plus a same-host iPad control.
On Android, host discovery, task listing, and Android-to-Mac execution all work. Only existing-task history and response hydration fail, while the identical task opens normally on iPad and Desktop.
I am leaving this issue open so maintainers can determine whether the shared Android symptom has the same root cause. I will close it if they confirm that it should be consolidated.
I reproduced this on another Android device and a newer Codex Desktop build.
Environment:
SM-S931U1.2026.22326.818.31338The Android client loaded the host, project, and task list. When I selected an existing task with a long history, the Android conversation view remained on gray skeleton placeholders.
The desktop logs recorded this sequence in local time:
14:49:22.180: the desktop receivedthread/resumefor the existing task and prepared a resume response with no active turn; Android remained on gray skeletons.14:50:45.663: the desktop receivedthread/startfor a new Android-created control task in the same project and on the same Remote connection.14:51:04.071: the desktop receivedturn/startforping.14:51:07.486: the desktop emittedturn/completedwith the responsePong.The log timestamps place
turn/completed3.415 seconds afterturn/start. The persisted task record reports a turn duration of 3.386 seconds.Pong.rendered on Android normally.The 18.408 seconds between
thread/startandturn/startincludes the time between creating the task and sendingping, so I am not treating it as app or network latency.Separately, I observed roughly 16 seconds from sending
pinguntil the Thinking state appeared, followed by about 10 more seconds before the response appeared. This was a manual phone observation and was not synchronized with the desktop timestamps, so I cannot reliably divide it into request, turn, or rendering latency.This adds desktop-side evidence for the same existing-task versus new-task split described in this issue. I omitted task, account, environment, installation, host, and request identifiers.