Android Remote message queue can stay stuck after host turn completes; recovery may lose or delay messages

Summary

Android Remote can accept user-authored messages into its visible queue without delivering them to the Windows Codex host. The mobile client can remain stuck showing an active Stop control even after the authoritative host turn has completed.

Two outcomes were captured with synchronized Android and Windows evidence:

1. Force-stop recovery: six queued messages never reached the host. Force-stopping and reopening ChatGPT cleared the stale state but silently discarded the queue.
2. Thread-switch recovery: two queued messages remained pending for roughly 38–41 minutes, then finally reached the host after I switched to another task, successfully sent messages there, and returned to the affected task.

The common theme is that Android displays input as queued, but the intended Codex task does not receive it promptly or durably.

Environment

• ChatGPT Android: 1.2026.230 (versionCode=2623032)
• Codex for Windows: 26.825.5331.0
• Windows 10 Home 22H2 x64, build 19045.7663
• Official Android Remote surface connected to the Windows host
• Observed August 29, 2026

Raw artifacts are retained locally. The excerpts below remove account/device/task IDs, local paths, host names, PIDs, UIDs, and private message contents.

Reproduction A: continuous 21:07–21:18 capture ends in stale Stop state and six-message loss

This failure did not begin at force-stop. The captured sequence starts with an image-steering failure, continues through repeated Android composing/attachment activity, host turn completion, six visible queue entries that never reach the host, three screenshots of the stuck state, and finally destructive recovery.

Full cross-device timeline (PDT)

• 21:07:27.823: the Windows rollout receives a text-only message reporting that the photo failed to steer. No image item accompanies it.
• 21:07:31–21:07:40: Android logs ChatGPT composer/IME activity: the keyboard is shown, then hidden.
• 21:08:24: an Android screenshot captures the active Remote failure state.
• 21:08:26.509: the Windows rollout receives the next text-only follow-up.
• 21:09:07: Android shows the ChatGPT IME/composer becoming active again.
• The first live Android log file ends at 21:09:23. A retained-buffer capture resumes before the stale-queue screenshots; the gap is disclosed rather than inferred over.
• 21:12:22.048: Android WindowManager returns focus to ChatGPT.
• 21:12:29.425: the Windows rollout finally receives the request to pause and accept the backlogged photos.
• 21:12:51.567: the authoritative Windows rollout records task_complete.
• 21:12:52.321 and 21:13:00.211: Android refreshes the ongoing codex_remote_session notification.
• Starting just afterward, Android accepts six additional user-authored messages into visible queue chips.
• 21:13:14–21:13:16: ChatGPT opens the system Photo Picker and returns to the thread.
• 21:15:29–21:15:33: Android SmartCapture takes the first retained screenshot, then returns focus to ChatGPT.
• 21:15:44–21:15:47: ChatGPT opens the Photo Picker again and returns to the thread.
• 21:15–21:16: the screenshots show all six messages still pending with ellipsis menus while the composer incorrectly continues to show the square Stop control. Later messages do not dispatch.
• 21:16:28–21:16:31: Android takes another screenshot and returns focus to ChatGPT.
• 21:16:48–21:16:49: Android takes the third screenshot and returns focus to ChatGPT.
• Across this interval, the Windows rollout contains zero corresponding user_message records for the six queue chips.
• 21:16:51.248: Android leaves ChatGPT for the launcher/recents path.
• 21:16:57.865: Android Settings force-stops ChatGPT.
• 21:16:57.869: Android kills the old ChatGPT process.
• 21:16:57.935: the ongoing codex_remote_session notification is removed.
• 21:17:03.626 and 21:17:04.128: initial ChatGPT relaunch attempts fail.
• 21:17:10.870: Android starts a new ChatGPT process.
• 21:17:12.662: the Codex Remote foreground service restarts.
• After reopening, the stale Stop state is gone—but all six queued messages are also gone.
• 21:18:37.728: the next host-visible user input is a newly submitted three-photo bundle after restart, not any of the six queued messages.

Sanitized Android log excerpt: interaction, queue wedge observation, and recovery

21:07:31.820  ChatGPT/IME     request show keyboard in com.openai.chatgpt.MainActivity
21:07:40.351  ChatGPT/IME     request hide keyboard in com.openai.chatgpt.MainActivity
21:09:07.319  ChatGPT/IME     keyboard visible in com.openai.chatgpt.MainActivity

               [live log file ends 21:09:23; retained-buffer capture resumes]

21:12:22.048  WindowManager  focus NotificationShade -> com.openai.chatgpt.MainActivity
21:12:52.321  ChatGPT        notify channel=codex_remote_session
21:13:00.211  ChatGPT        notify channel=codex_remote_session
21:13:12.784  WindowManager  focus -> com.openai.chatgpt.MainActivity
21:13:14.873  WindowManager  focus ChatGPT -> system Photo Picker
21:13:16.822  WindowManager  focus Photo Picker -> ChatGPT
21:13:48.879  WindowManager  focus ChatGPT -> NotificationShade
21:13:49.981  WindowManager  focus NotificationShade -> ChatGPT
21:14:00.246  WindowManager  focus NotificationShade -> ChatGPT
21:15:29.937  WindowManager  focus ChatGPT -> SmartCapture
21:15:33.822  WindowManager  focus SmartCapture -> ChatGPT
21:15:44.595  WindowManager  focus ChatGPT -> system Photo Picker
21:15:47.195  WindowManager  focus Photo Picker -> ChatGPT
21:16:28.864  WindowManager  focus ChatGPT -> SmartCapture
21:16:31.867  WindowManager  focus SmartCapture -> ChatGPT
21:16:48.434  WindowManager  focus ChatGPT -> SmartCapture
21:16:49.749  WindowManager  focus SmartCapture -> ChatGPT
21:16:51.248  WindowManager  focus ChatGPT -> launcher/recents
21:16:57.865  ActivityManager Force stopping com.openai.chatgpt
21:16:57.869  ActivityManager Killing <OLD_CHATGPT_PID>:com.openai.chatgpt
21:16:57.935  SystemUI       remove notification package=com.openai.chatgpt channel=codex_remote_session
21:17:03.626  ActivityManager Activity could not be started: com.openai.chatgpt/.MainActivity
21:17:04.128  ActivityManager Activity could not be started: com.openai.chatgpt/.MainActivity
21:17:10.870  ActivityManager Start proc <NEW_CHATGPT_PID>:com.openai.chatgpt
21:17:12.662  ActivityManager start FGS com.openai.feature.codexremote...CodexRemoteSessionForegroundService

The release Android build does not log queue item contents or explicit local queue mutations. The six queue chips and stale Stop control are therefore proven by the three screenshots; the log proves the surrounding ChatGPT focus, composer, Photo Picker, screenshot, force-stop, process, notification, and Remote-service lifecycle.

Sanitized Windows rollout excerpt: early text succeeds, then the six-chip queue never arrives

21:07:27.823  event_msg      user_message  message=<PHOTO_STEER_FAILED_TEXT>; images=[]
21:08:26.509  event_msg      user_message  message=<TEXT_FOLLOW_UP>; images=[]
21:12:29.425  event_msg      user_message  message=<PAUSE_FOR_BACKLOGGED_PHOTOS>; images=[]
21:12:51.409  agent_message  phase=final_answer
21:12:51.567  event_msg      task_complete

                 [zero user_message / image records corresponding to
                  the six Android queue chips]

21:18:37.728  response_item  user message with three newly submitted local images

This A/B boundary matters: the host successfully receives earlier text from the same Android session, then receives the pause request and completes the turn, but receives none of the six queue entries displayed afterward. The failure is not simply “Android had no connection.”

Reproduction B: switching away and back correlated with a 38–41 minute delayed queue drain

Timeline (PDT)

• The host turn completed at 23:05:16.030.
• Android interaction logs show two best-evidence send attempts at 23:05:33.538 and 23:05:36.752.
• Each attempt is immediately followed by a ChatGPT Remote foreground-service queue/status update and an app-UID keystore operation.
• A photo taken at 23:42 still shows both messages as queued ellipsis chips and the stale square Stop control.
• I switched to another task, successfully sent messages there, then returned.
• 23:42:54.226: host task settings were applied.
• 23:42:54.292: the affected host task reactivated.
• 23:43:53.623: context compaction completed.
• 23:43:54.613: queued message 1 reached the Windows rollout—about 38m 21s after the probable send tap.
• 23:46:44.588: queued message 2 reached the Windows rollout—about 41m 08s after the probable send tap.
• Neither message was ultimately lost in this reproduction.

Sanitized Android log excerpt: enqueue attempts and thread-switch recovery

23:05:33.538  system          PowerManagerService: userActivity touch
23:05:33.749  system          notification_enqueue package=com.openai.chatgpt channel=codex_remote_session
23:05:33.797  ChatGPT         NotificationManager: notify channel=codex_remote_session
23:05:35.322  keystore        create_operation success uid=<CHATGPT_UID>
23:05:36.752  system          PowerManagerService: userActivity touch
23:05:37.247  keystore        create_operation success uid=<CHATGPT_UID>
23:05:37.434  system          notification_enqueue package=com.openai.chatgpt channel=codex_remote_session
23:05:37.485  ChatGPT         NotificationManager: notify channel=codex_remote_session

                         [both messages remain visibly queued for more than 37 minutes]

23:42:22.582  WindowManager   move ChatGPT task to front
23:42:22.595  ActivityManager set resumed activity com.openai.chatgpt/.MainActivity
23:42:22.597  ActivityManager resume com.openai.chatgpt/.MainActivity
23:42:35–48    input           repeated touch interaction in ChatGPT
23:42:49.220  WindowManager   focus ChatGPT -> SmartCapture
23:42:52.450  WindowManager   focus SmartCapture -> ChatGPT
23:42:52.457  input_focus     focus request com.openai.chatgpt.MainActivity
23:42:54.809  ActivityManager start CodexRemoteSessionForegroundService
23:42:54.816  system          notification_enqueue package=com.openai.chatgpt channel=codex_remote_session
23:42:54.868  ChatGPT         NotificationManager: notify channel=codex_remote_session

The release Android build does not log message contents or explicit queue mutation records. The two touch → Remote-status/crypto sequences are the best-evidence original enqueue attempts. The later task-to-front/resume, SmartCapture, focus-return, Remote-service, and notification events independently corroborate the user’s switch-away/return sequence immediately before host delivery resumed.

Sanitized Windows rollout excerpt

23:05:16.030  event_msg  task_complete
                 [no affected-task events for approximately 37m 38s]
23:42:54.226  event_msg  thread_settings_applied
23:42:54.292  event_msg  task_started
23:43:53.623  compacted
23:43:54.613  event_msg  user_message  message=<QUEUED_MESSAGE_1>
23:46:44.588  event_msg  user_message  message=<QUEUED_MESSAGE_2>

Expected behavior

• Once Android displays a message as queued, it should be durably represented with a stable client ID and explicit state: local pending, server accepted, delivered, failed, or canceled.
• Mobile active-turn state should reconcile immediately when the host emits task_complete.
• The square Stop control should disappear when no host turn is active.
• Force-stopping/restarting the app should not silently discard user-authored queue entries.
• Switching tasks should not be required to trigger queue delivery.
• A stale queued item should be inspectable, retryable, and cancelable.
• A message that later drains must not remain eligible for duplicate delivery.

Actual behavior

• Android can retain a stale running-turn state after the host is finished.
• New messages remain client-side and are absent from the host rollout.
• Force-stop clears the state by discarding the pending queue.
• Alternatively, reopening/reactivating the task may flush messages tens of minutes late.
• The UI provides no reliable accepted/delivered/failed distinction.

Likely boundary

The paired evidence is consistent with a mobile queue/subscription reconciliation failure across the Android Remote client, relay/session state, and host task lifecycle. It is not consistent with ordinary loss of Internet connectivity: the host remained online, other tasks accepted messages, and the affected messages could later drain.

That is an inference, not a confirmed root cause.

Workarounds observed

• Destructive workaround: force-stop and reopen ChatGPT. This restores the composer/state but can discard every queued message.
• Non-destructive workaround that sometimes helps: switch to another task, successfully send there, then reopen the affected task. In one capture this correlated with the delayed queue finally draining, but it is not proven reliable.

Related reports

Closest Android/mobile Remote reports

• #36831 — mobile steer remains stuck in Sending, blocks further input, and cannot be inspected or canceled
• #25268 — Android queued message disappears after backgrounding/thread reload
• #38023 — Android Remote turn/start times out while a message remains Sending and the task shows stale Thinking
• #37785 — image-bearing Android steering can lose or defer the attachment even when accompanying text reaches the host

Same stale completed-turn / local-queue state on other surfaces

• #34026 — Windows Desktop shows completed threads as still thinking; new messages remain local queue cards and cannot start
• #34021 — Desktop/remote queue requests are silently ignored in some threads
• #31100 — VS Code follow-up prompts submitted during active work disappear instead of being processed later
• #38055 — Windows SSH Remote messages enter an ambiguous delayed queued/Steer state

Queue ownership / lifecycle adjacency

• #33416 — remote follow-up queue dispatch depends on the originating controlling desktop remaining awake
• #39954 — Android interactive Remote session can die independently while the host task continues; messages may target disconnected logical connections
• #18860 — analogous stale client/host lifecycle divergence

These reports span Android, iOS/macOS Remote, Windows Desktop, SSH Remote, and VS Code. They suggest that the underlying queue/lifecycle problem is broader than this specific Windows + Samsung reproduction, while #41708 contributes synchronized Android and Windows evidence for both destructive and non-destructive recovery paths.

Evidence retained

• android-steer-20260829-210726.log: Android ChatGPT process log, approximately 21:07:27–21:09:23
• android-steer-failure-20260829-210824.png: screenshot captured during the initial image-steering failure
• android-stale-stop-full-2111-2119.log: full retained Android system/app window covering the stale Stop/queue state through force-stop and relaunch
• Three Android screenshots showing six pending queue chips and the stale Stop control
• One Android screenshot showing the two delayed queue chips shortly before non-destructive recovery
• Full Android logcat window for the delayed-drain reproduction
• Matching Windows rollout slices from 21:07–21:19 and 23:05–23:47
• Exact cross-device timestamps used above

The raw files are intentionally not attached because they include unrelated app activity, private message text, local paths, and task/host identifiers. The expanded sanitized excerpts preserve the relevant interaction, focus, picker, screenshot, notification, process, Remote-service, host-receipt, and non-receipt sequence.

No source files, entry points, or tests are named in the issue. Start by locating the Android Remote queue and host task-completion reconciliation paths, then trace how queued messages are persisted and dispatched. Done means queued messages survive restart, reconcile after task completion, deliver without a task switch, and expose reliable retry or cancellation states.