[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 build 6872)
• Android device A: primary Samsung Galaxy Ultra phone (exact model/build not independently captured)
• Android device B: SM-F721N, Android 16 (SDK 36)
• ChatGPT on device B: 1.2026.223
• Control client: iPad (exact model/app build not yet captured)

Controlled observations

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?

1. Run ChatGPT/Codex Desktop on macOS with Remote enabled.
2. Open an existing task on Desktop and confirm its history renders normally.
3. On ChatGPT Android, select the same Mac host and project.
4. Confirm that the host shows a green connected indicator and that the task list loads.
5. Open the existing task.
6. Observe that the conversation body remains on gray skeleton placeholders indefinitely.
7. Create a new task from Android on the same host/worktree.
8. Observe that the new Android-created task opens and updates normally.
9. Sign in and connect a second Android device to the same host.
10. Open the same existing task and observe the same indefinite gray skeleton.
11. Open the same existing task through Remote on an iPad connected to the same Mac host.
12. 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.

No files, tests, or code entry points are identified in the report. Start by tracing the Android Remote path for opening existing tasks and compare it with the working new-task and iPad flows; done means existing task history and new responses hydrate on Android across the reported devices.