iOS mobile control shows Codex run failed after completed turn when bridge restarts

[johnsilvavlogs]

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

Pro

Which model were you using?

Observed with GPT-5.5 from the mobile Codex control surface. A smaller project-specific smoke run used GPT-5.5 Low and completed successfully.

What platform is your computer?

macOS 26.3, build 25D125

Codex Desktop app:

• CFBundleShortVersionString: 26.513.20950
• CFBundleVersion: 2816

Remote control was enabled via features.remote_control = true; codex features list reports remote_control under development true.

What issue are you seeing?

The ChatGPT iOS Codex/mobile-control UI showed an orange Codex run failed. banner under a thread that had already rendered a completed final answer.

This looks like a stale failure state after the local codex remote-control bridge was restarted/replaced, not an actual failed turn:

• The completed session has a local task_complete event and the expected assistant final answer.
• The desktop/app-server log shows normal thread/list, thread/read, and later turn/start/completed activity with errorCode=null after the banner appeared.
• A later mobile-origin run completed successfully through the same Mac after the bridge was running again.
• The bridge process had logged that the remote-control WebSocket reader/writer stopped when the old foreground bridge process was terminated.

Because the mobile UI shows the completed answer and then still says Codex run failed., it is hard for the user to tell whether the work failed, whether only the bridge disconnected, or whether the banner is stale.

I am not uploading the screenshot here because it includes a personal local hostname, but the screenshot shows a completed mobile-control thread with the orange Codex run failed. banner below the final answer.

Reproduction

1. Enable remote control on macOS:

   [features]
   remote_control = true

2. Start the bridge:

   codex remote-control

3. Pair ChatGPT iOS Codex/mobile control with the Mac.
4. Start a mobile Codex run against an explicit local project.
5. Let the run complete. In my case the assistant final answer rendered successfully.
6. Restart or replace the local codex remote-control bridge after completion, for example by moving it from a foreground terminal process to a launchd-managed process.
7. Reopen the completed thread in ChatGPT iOS.

Expected behavior

If the turn has completed, the mobile thread should remain completed. If the bridge disconnects after completion, the UI should either ignore that for the completed turn or show a connection-specific status such as "connection interrupted/reconnected" instead of marking the completed run as failed.

Actual behavior

The completed thread shows an orange Codex run failed. banner below the final answer.

Evidence from this run

• Session 019e2834-e1ac-7242-b1b3-92c052a55e5f completed at 2026-05-14T20:38:47.217Z with task_complete, duration 2568ms, final answer mobile control connected.
• Foreground bridge shutdown shortly afterward logged:
  • remote control websocket writer was stopped
  • remote control websocket reader was stopped
• After the bridge was restarted, launchd reported the new bridge job as state = running, last exit code = (never exited).
• The remote-control enrollment was refreshed for the same Mac hostname.
• Later desktop log entries for mobile-origin activity showed errorCode=null, and a later mobile-origin session completed successfully.

Possible secondary issue

Before selecting an explicit project, a projectless mobile-control smoke run failed with a generic CodexClientError error 10/11. Selecting an explicit project and using a lower reasoning setting allowed the smoke run to complete. If projectless mobile runs are unsupported or fragile, the mobile UI could use a clearer error.

[johnsilvavlogs]

Additional occurrence: banner shown while the desktop-side run completed normally

Observed another instance on 2026-05-15 around 20:00 America/Sao_Paulo.

Environment:

• Codex Desktop 26.513.20950, build 2816
• App-bundled CLI/runtime: codex-cli 0.131.0-alpha.9
• Homebrew CLI: codex-cli 0.130.0
• macOS 26.3 (25D125), arm64
• ChatGPT iOS Codex/mobile-control UI, Pro account
• Model on the affected run: gpt-5.5, reasoning xhigh

What the iOS UI showed:

• Thread title: Plan retention cleanup
• Project/context: HealthLens on Johns-MacBook-Pro.local
• Visible assistant update ended with: I’ll close it and base the dry run on the primary evidence.
• Directly below that update, the mobile UI displayed the orange banner: Codex run failed.

Local evidence says the displayed HealthLens cleanup run did not actually fail:

• Affected thread id: 019e2dd8-c9e4-71f3-8ebc-c7bec206cb78
• Cwd: /Users/johnsilva/Desktop/HealthLens
• Session source: vscode, thread_source=user
• Original cleanup turn id: 019e2dd8-d1d9-7980-a4e2-59bd560c0268
• The cleanup run emitted its final dry-run answer at 2026-05-15T23:00:42.529Z
• It then emitted task_complete at 2026-05-15T23:00:42.553Z
• Duration was 397787ms
• The final answer asked for yes/no before deleting anything; no deletion was executed.

Possible correlation:

• Around 2026-05-15T23:00:26.844Z, local logs showed a separate/internal failure:
  ERROR codex_core::tools::router: error=apply_patch verification failed
• That failure was in thread 019e2dd8-8913-7532-9e3d-17a26155caf7, against /Users/johnsilva/.codex/memories/MEMORY.md.
• It was not the HealthLens cleanup command and did not prevent the visible cleanup turn from completing.

Why this extends this issue:

• The original report looked like a stale failure banner after a completed turn plus bridge restart.
• In this occurrence, the banner appeared on the mobile surface while the visible run was still recoverable/progressing and the desktop-side transcript later completed successfully.
• There was no obvious bridge restart as the immediate trigger.
• The common failure mode is that the iOS mobile-control UI can show Codex run failed. even though the displayed thread is not failed according to the local transcript/task state.