›_ Codex Issues
Codex Issues / #22831

Codex iOS app: "Network connection was lost" repeatedly when connecting to remote SSH host (codex-cli 0.130 on Debian 12)

Resolved 💬 4 comments Opened May 15, 2026 by neilsanghrajka Closed Aug 4, 2026

What version of the Codex App are you using (From "About Codex" dialog)?

Codex iOS app — latest from App Store as of May 15, 2026.

What subscription do you have?

Pro

What platform is your computer?

  • Codex iOS app: iPhone, iOS 18.x
  • Codex desktop app (used as control case): Darwin 25.4.0 arm64 arm

What issue are you seeing?

The Codex iOS app's Add SSH Host flow consistently fails with Network connection was lost (repeating indefinitely) when targeting a remote Linux VM, while the Codex desktop app on macOS connects successfully to the exact same host with equivalent credentials.

Remote host:

  • codex-cli 0.130.0 installed at /usr/bin/codex (via npm i -g @openai/codex)
  • codex login status → Logged in using ChatGPT
  • Debian 12 (bookworm), x86_64, Linux kernel 6.1
  • bubblewrap installed at /usr/bin/bwrap
  • Reachable via private VPN (Tailscale); both iOS and macOS clients on the same tailnet
  • SSH password auth enabled; key auth also available

Observed on the VM during iOS connection attempts:

  • sshd auth log: multiple Accepted password for <user> from <iOS Tailscale IP> entries — SSH layer succeeds.
  • pgrep -af codex shows codex app-server --listen unix:// running, started by iOS's SSH session.
  • ~/.codex/app-server-control/app-server-control.sock exists; held by codex (verified with lsof).
  • ~/.codex/app-server-control/app-server.log is empty after cleanup — no error logged when iOS attempts.
  • iOS SSH session disconnects within ~5s after each attempt; app retries; loops with Network connection was lost.

Control case (works): Codex macOS desktop app, same VM, same SSH config alias. Threads launch normally; codex app-server bridges over SSH; everything works.

Looks adjacent to / possibly same root cause as:

  • #22823 — Remote SSH to (DevPod) devcontainer fails with app server did not become ready on .../app-server-control.sock. Same control-socket failure pattern, different platform.
  • #12236 — iOS URLSessionWebSocketTask rejecting Sec-WebSocket-Extensions: permessage-deflate. The workaround in that issue applies to --listen ws:// setups, not the Unix-socket auto-launch flow the Codex iOS app uses.

What steps can reproduce the bug?

  1. Provision a Linux VM (Debian 12, x86_64).
  2. Install Node 20 and npm i -g @openai/codex → codex-cli 0.130.0.
  3. Run codex login on the VM and authenticate via ChatGPT.
  4. Make the VM reachable from an iOS device (in my setup, via Tailscale; password SSH auth enabled on the VM).
  5. Open Codex iOS app → Add SSH Host → enter the VM's IP, port 22, username, password → Save.
  6. Tap the host to connect / start a thread.

Expected: iOS app connects and starts a Codex thread on the VM, matching the Codex desktop app behavior on macOS against the same host.

Actual: iOS app spins indefinitely showing Network connection was lost. SSH layer authenticates (visible in journalctl -u ssh); codex app-server process starts; but the iOS client never establishes a working session.

What is the expected behavior?

The iOS app should connect and start a Codex thread on the remote VM successfully, matching the Codex macOS desktop's behavior against the same host.

Additional information

  • Codex desktop on macOS connects to the same VM via the same SSH alias and works correctly — both can't connect simultaneously due to the \app-server-control.sock\ lock, but each works in isolation... except iOS never does.
  • When iOS attempts to connect, no error is logged in \~/.codex/app-server-control/app-server.log\ on the remote host. The failure is silent server-side and surfaces only as \Network connection was lost\ on the client.
  • Happy to provide additional diagnostics (sshd debug logs, codex-cli trace, packet capture from the VM side) if useful.

View original on GitHub ↗

4 Comments

jeremytondo · 3 months ago

Not sure if this will help you or not, but after a few hours of digging I found that the iOS connection flow was trying to run nc -U in order to make the connection to the codex server after successfully starting it up. I didn't have that on my machine so I fixed this by installing openbsd-netcat and now things seem to be working.

neilsanghrajka · 3 months ago

This worked!

danohn · 3 months ago

Thank you! On Debian 13 the command to install is sudo apt install -y netcat-openbsd

RealColdFry · 3 months ago

I hit what looks like the same failure mode and narrowed it down to Debian/Ubuntu nc.traditional.

On my host, iOS direct SSH auth succeeded, codex app-server --listen unix:// was running, and the control socket existed, but the iOS app immediately dropped with the generic connection error. Tracing execs on the host showed the iOS SSH flow invoking nc against:

~/.codex/app-server-control/app-server-control.sock

In my case /usr/bin/nc resolved to nc.traditional. Running the app-server in the foreground with RUST_LOG=debug showed:

failed to upgrade control socket websocket connection: WebSocket protocol error: Handshake not finished

Switching nc to OpenBSD netcat fixed the iOS connection immediately:

sudo apt install netcat-openbsd
sudo update-alternatives --set nc /bin/nc.openbsd