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

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:

``toml
[features]
remote_control = true
``

1. Start the bridge:

``bash
codex remote-control
``

1. Pair ChatGPT iOS Codex/mobile control with the Mac.
2. Start a mobile Codex run against an explicit local project.
3. Let the run complete. In my case the assistant final answer rendered successfully.
4. 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.
5. 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.