macOS Codex App repeatedly resets healthy Remote Control streams with "stream became unknown" and sequence gaps

What version of the Codex App are you using?

• Codex App: 26.707.31428
• Bundle: 5059
• Bundled codex-cli: 0.144.0-alpha.4

What platform are you using?

• macOS 27.0 (26A5378j)
• Apple Silicon / arm64

Remote hosts

I can reproduce this with two independent Linux servers from different providers:

• Hetzner
• IONOS

Both hosts run Codex app-server 0.144.1 using managed Remote Control. The two servers do not share infrastructure, networking, or systemd units.

Summary

The Codex macOS App repeatedly loses an individual Remote Control app-server stream for approximately 2–4 seconds and then reconnects.

The recurring errors are:

remote control app-server stream became unknown
remote control app-server stream sequence gap detected

Both remote app-server daemons remain running with unchanged PIDs during the failures. Their Unix control sockets remain healthy, and no host-side restart, OOM event, network-interface outage, or systemd restart occurs.

The same failure pattern has been observed on both remote hosts. At one point, both environments reported sequence-gap failures within about 13 seconds of each other.

Example event

At 2026-07-10 19:27 CEST / 17:27 UTC:

1. 19:27:34.949 — the existing long-lived TCP connection was closed cleanly. The first observed TCP FIN was sent by the macOS endpoint. Because the connection is TLS-encrypted, this does not rule out an earlier WebSocket Close frame from the relay.
2. 19:27:35 — the socket watcher observed no established connection.
3. 19:27:37.724 — macOS initiated a new TCP connection to the same OpenAI/Cloudflare endpoint.
4. 19:27:40.955 — the Codex App closed the affected app-server stream with code 4000:

app_server_connection.closed
code=4000
reason="remote control app-server stream sequence gap detected"
transport=websocket

1. 19:27:41.957 — reconnect started.
2. 19:27:43.555 — the app-server stream was connected and initialized again.

The user-visible interruption lasted approximately 2.6 seconds.

Shortly before this event, at 19:25:35.945, the same environment was reset with:

app_server_connection.closed
code=4000
reason="remote control app-server stream became unknown"
transport=websocket

That earlier stream reset did not coincide with replacement of the underlying shared TCP connection.

Relevant sanitized logs

2026-07-10T17:25:35.945Z
app_server_connection.state_changed
cause=transport_closed
closeCode=4000
connectionError={
  "code": "connection-failed",
  "message": "remote control app-server stream became unknown"
}
previous=connected
next=error
transport=websocket

2026-07-10T17:27:40.955Z
app_server_connection.state_changed
cause=transport_closed
closeCode=4000
connectionError={
  "code": "connection-failed",
  "message": "remote control app-server stream sequence gap detected"
}
previous=connected
next=error
transport=websocket

The corresponding remote-host checks showed:

app-server PID: unchanged
pid-update-loop PID: unchanged
app-server version: 0.144.1
control socket: healthy
systemd service: active
OOM/restart event: none

Local network checks

During the captured events:

• the macOS default route remained present;
• Wi-Fi interface en0 remained up;
• IPv4, IPv6, and DNS remained reachable;
• no ERR_NETWORK_CHANGED event was logged;
• no TCP RST was observed;
• both remote hosts remained reachable independently.

Expected behavior

A temporary reconnect of the shared relay WebSocket should resume all Remote Control streams without producing an observable sequence gap.

If the relay cannot resume a stream, the App should log enough information to identify the failing boundary, including:

• shared WebSocket close code and close reason;
• whether the close was local or received from the relay;
• last successful ping and pong;
• previous and received stream seq_id;
• resume/subscription cursor;
• relay connection generation ID;
• whether the stream was reported as unknown by a pong/status response.

Actual behavior

The App intentionally closes the affected stream with code 4000 after receiving an unknown stream status or detecting a sequence gap. It then reconnects successfully, but the short outage repeats every few minutes.

Related issues and changes

• #29262 — same remote control app-server stream became unknown error on the macOS desktop app
• #30301 — stalled/failed Remote Control relay generations and missing in-process recovery
• #21572 — stream sequencing hardening and stream-scoped gap recovery
• #17902 — per-stream sequence IDs to prevent apparent gaps caused by interleaved streams

The behavior strongly suggests a problem in the desktop-to-relay WebSocket lifecycle or relay stream resume/cursor handling rather than a failure of either remote app-server.

Is the shared Remote Control WebSocket expected to be recycled this frequently? Are there known cases where reconnect/resubscribe returns incomplete stream history or reports a still-active stream as unknown?