iOS Remote Control reconnects after briefly backgrounding ChatGPT and takes 10+ seconds every time

Open 💬 2 comments Opened Aug 11, 2026 by pavlov-asuka

What platform are you using?

  • Host: Windows 11 running Codex Desktop / Remote Control
  • Client: ChatGPT iOS app (1.2026.202), iOS 26.6
  • Subscription: ChatGPT Plus

What issue are you seeing?

Codex Remote Control from the ChatGPT iOS app is consistently very slow to connect to an already-running desktop host. A normal connection commonly takes 10+ seconds before the host/thread becomes usable.

More importantly, the connection does not appear to survive a very ordinary iOS app lifecycle transition:

  • Connect successfully to the desktop Codex host from ChatGPT on iOS.
  • Switch out of ChatGPT to another iOS app.
  • Switch back to ChatGPT shortly afterward.
  • Codex Remote Control starts reconnecting again instead of immediately resuming the existing connection/session.
  • The reconnect again takes roughly 10 seconds or more.

This makes Remote Control feel much slower than a normal mobile companion/control surface, because even briefly leaving ChatGPT can incur the full connection delay again.

The desktop Codex host remains open, online, and usable locally throughout this process. The slow path appears to be the mobile Remote Control reconnect/resume path rather than starting Codex itself.

What steps can reproduce the bug?

  1. Keep Codex Desktop running on a Windows 11 PC with Remote Control enabled.
  2. Open ChatGPT on iPhone and go to Codex Remote Control.
  3. Connect to the Windows host and wait until a thread is usable.
  4. Switch from ChatGPT to another iOS app.
  5. After a short time, switch back to ChatGPT.
  6. Return to the Codex Remote Control view.
  7. Observe that the client reconnects to the host instead of resuming immediately.
  8. The reconnect commonly takes 10+ seconds before the remote thread is usable again.
  9. Repeat steps 4-8. The delay is reproducible repeatedly.

What is the expected behavior?

If the desktop host is still online and the same authenticated iOS client returns after a short foreground/background transition, Remote Control should resume nearly instantly.

Ideally:

  • Briefly backgrounding ChatGPT should not tear down the effective remote session.
  • If iOS suspends the socket, the client should restore/resume the existing session quickly rather than perform a full cold reconnect/state hydration path.
  • The UI should remain usable while reconnection completes where possible (for example, allowing the user to type/queue a message rather than blocking the entire control surface).
  • A warm reconnect to an already-running host should be on the order of a second or a few seconds, not consistently 10+ seconds.

Actual behavior

Every time the mobile connection has to reconnect, the user is blocked for roughly 10 seconds or longer. Simply switching away from ChatGPT and returning can trigger this cost again.

This makes frequent mobile steering impractical: checking another app, copying information, reading a notification, or briefly locking/switching apps can turn into another long wait before Codex can be controlled again.

Related issues

This appears related to the broader Remote Control reconnect/performance problem reported in:

  • #25495 — Codex App Remote Control is really slow on reconnecting.
  • #23482 — macOS remote control stalls: host app-server responsive but remote manager stays disconnected

This report adds a narrower and highly reproducible iOS foreground/background lifecycle case: an already-connected, already-running host repeatedly incurs a 10+ second reconnect after leaving and returning to the ChatGPT app.

Suggested investigation

It may be useful to measure the foreground-resume path separately from an initial cold connection and determine whether the iOS client is unnecessarily repeating host discovery, relay setup, app-server initialization, thread listing, or full state hydration after a short background transition.

A resumable/warm connection path with cached host/thread state would make the feature feel dramatically more responsive.

Additional information

The host remains running and locally responsive while the iOS app is backgrounded. This is not a case where the desktop host has gone to sleep or Codex has been restarted.

The problem is especially noticeable because Remote Control otherwise works well once the connection is established; the recurring 10+ second reconnect delay is the main usability bottleneck.

View original on GitHub ↗

2 Comments

junbaor · 10 days ago

+1, same experience here — and I suspect network geography makes it worse.

I'm in China. When controlling my desktop Codex host from the ChatGPT mobile app, every single connection is extremely slow (often 30s+, sometimes it fails and retries). This isn't limited to the reconnect-after-backgrounding case described above — even a fresh, deliberate "connect" from the phone is slow every time.

Some observations that may help narrow it down:

  • The desktop host stays online and fully usable locally; it's specifically the mobile → desktop Remote Control path that's slow.
  • Since the connection appears to be relayed rather than LAN-direct, users far from the relay (e.g. mainland China, even with a stable proxy) seem to pay a much higher penalty per connection.
  • Once connected, sending messages is usually fine — it's the initial connect/reconnect handshake that hurts.

Would love to see a faster handshake, a session that survives app switches, or regional relay servers.

dqieu · 9 days ago

I'm reconsidering migrating from Claude because this breaks one of my core workflows. The cool thing about mobile is I can drop in anywhere anytime. Often it's to drop a follow-up I just come up while doing other work. Having to wait 30s every time is distracting and ancient. I also can't rely on being notified to jump in if the connection isn't stable. Zero issues with Claude Code.