Codex iOS remote live updates silently stop on Windows host; full app restart resumes already-complete thread

What issue are you seeing?

Codex iOS remote control can silently stop applying live updates while connected to a Windows Codex host. The mobile app does not show a reconnect banner for the paired host. Long-running command phases make the chat appear hung on mobile, but host-side evidence shows the desktop task completes normally. Fully restarting the iOS app restores the completed thread state.

Reporter can respond via this GitHub issue. Private logs and exact local identifiers can be provided on request through an appropriate private channel.

Environment

• Host OS: Windows
• Codex Windows app: OpenAI.Codex 26.616.3309.0
• Host name shown to mobile: redacted local Windows host display name
• iOS remote client observed in app-server logs: codex_chatgpt_ios_remote
• iOS remote client version observed: 1.2026.153
• Workspace type: Windows/NAS-backed workspace, exact local path redacted
• Codex thread/app-server state database: local Codex state database path redacted
• Codex logs database: local Codex logs database path redacted

Expected behavior

If the desktop task is still running, iOS should continue receiving live updates or show a clear reconnect/stale-state indication.

If the mobile live-update stream wedges, the app should detect and recover automatically, or show an explicit reconnect/error state. It should not require a full iOS app restart to display an already-completed thread.

Actual behavior

The iOS app remains visually stale/hung on command output, with no reconnect banner. Backing out/reopening was not sufficient in the latest reproduction; fully restarting the iOS app restored the completed task state.

Host-side evidence shows the task had already completed before the iOS restart/resume.

Concrete reproduction/evidence from latest incident

Affected thread and local transcript identifiers are redacted from the public issue. They can be provided privately if needed.

Timeline:

• 2026-06-19T13:22:06.008Z to 2026-06-19T13:23:09.760Z: command ran for about 63.752s
• command type: repository context-packet generation script
• This explains why the mobile view appeared command-stuck, but not why the app needed a full restart.
• 2026-06-19T13:25:17.500Z: host rollout recorded task_complete for the affected thread.
• 2026-06-19T13:25:37.808329Z: app-server logged a resume response for the same thread with active_turn_present=false.
• 2026-06-19T13:26:11.171373Z: app-server logged codex_chatgpt_ios_remote client version 1.2026.153 issuing thread/resume against the same thread, again with active_turn_present=false.

Representative app-server evidence, sanitized:

2026-06-19T13:25:37.808329Z
codex_app_server::request_processors::thread_lifecycle
composing running thread resume response
thread_id=<redacted affected thread id>
active_turn_present=false
connection_id=27

2026-06-19T13:26:11.171373Z
codex_app_server::thread_state
rpc.method="thread/resume"
app_server.client_name="codex_chatgpt_ios_remote"
app_server.client_version="1.2026.153"
thread_id=<redacted affected thread id>
had_active_turn=false
connection_id=28

Retained desktop stream evidence near final answer:

• 2026-06-19T13:25:11.387397Z to 2026-06-19T13:25:14.353752Z
• 500 retained rows for the affected thread in the local Codex logs database
• largest observed desktop-side telemetry gap in that retained slice: about 0.064s

This suggests the desktop-side response stream was dense/healthy during final output, while the iOS remote live view was stale.

Earlier related local observations

Two other tasks had the same user-visible pattern: the mobile app appeared stuck, then a full app restart showed both chats already complete.

• Another affected thread completed at 2026-06-19T12:04:01Z
• Second affected diagnostic thread completed at 2026-06-19T12:05:00Z
• App-server later showed a resume response for one affected thread with active_turn_present=false

Why this appears distinct from a host/network command hang

The host had already been separately investigated for network issues:

• Earlier IPv6 source-selection problems were mitigated by avoiding broken local IPv6 source prefixes and using a working local IPv6 source or IPv4.
• Fresh chatgpt.com TCP checks around the earlier incident were healthy (37-53ms).
• Current Codex-owned sockets were established over a working IPv6 source or IPv4.
• Desktop rollout files show tasks completing normally.

The observed failure is therefore specifically: mobile live update state becomes stale without a reconnect banner, and a full iOS app restart forces a thread/resume that returns an already-complete thread.

Related issues found before filing

This may be related to, but is narrower than, existing remote-control stale-state reports such as:

• #24024 remote control stale/contradictory state after idle or network changes
• #24179 remote-control product state diverging from desktop WebSocket/TCP state
• #24454 mobile session list stale while desktop has newer sessions

This report is specifically about an iOS remote live thread view silently stopping updates while the Windows host thread completes, then recovering only after full iOS app restart and thread/resume.

Logs and privacy

Local logs/session paths are available on the reporter machine. They may contain private workspace/session data, so raw logs and exact local identifiers have not been attached publicly. Sanitized evidence is included above. The reporter can provide selected excerpts if needed.