Repository navigation
macOS Codex App repeatedly resets healthy Remote Control streams with "stream became unknown" and sequence gaps #32241
Description
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:
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.19:27:35— the socket watcher observed no established connection.19:27:37.724— macOS initiated a new TCP connection to the same OpenAI/Cloudflare endpoint.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
19:27:41.957— reconnect started.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
en0remained up; - IPv4, IPv6, and DNS remained reachable;
- no
ERR_NETWORK_CHANGEDevent 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
unknownby 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
- Remote Control from macOS desktop drops Mac mini connection when opening remote threads #29262 — same
remote control app-server stream became unknownerror on the macOS desktop app - Recover stalled Remote Control relay generations in-process #30301 — stalled/failed Remote Control relay generations and missing in-process recovery
- remote-control: harden stream sequencing #21572 — stream sequencing hardening and stream-scoped gap recovery
- app-server: track remote-control seq IDs per stream #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?
Activity
austintraver commentedon Jul 16, 2026
Additional corroboration from a different setup on 2026-07-16:
26.707.72221/ bundle5307, bundled Codex CLI0.144.2.01:06:50.148Zand01:06:50.195Z, both streams were closed only 47 ms apart with code4000andremote control app-server stream sequence gap detected.thread/readrequests with-32000 Codex app-server is not available, including resume metadata reads.This makes a single host-side networking or app-server failure less likely.
Related distinction: an earlier reconnect had yielded
Invalid request: AbsolutePathBuf deserialized without a base pathwhen resuming an idle remote thread. This time there was no newAbsolutePathBufentry: the resume attempt first failed because the app-server stream was unavailable. That makes the path error look like a possible follow-on recovery bug, consistent with #31983, rather than the cause of the sequence gap.poer2023 commentedon Jul 16, 2026
Additional corroboration with a distinct user-visible impact: background Remote Control reconnect storms can affect an unrelated local task.
Environment:
26.707.91948(bundle5440)26.5.2, Apple SiliconDuring an approximately 30-minute reproduction window:
remote control app-server stream sequence gap detected.inProgresswith no task error and continued producing messages and completing tool calls successfully.error,failed, orabortedevents were found.The reconnect attempts were also followed by
Codex app-server initialize handshake timed out.Network checks during the same period completed 240 requests across three relevant OpenAI endpoints with zero transport failures and expected HTTP statuses. The Desktop log window contained no
ERR_SSL,tls handshake eof, orstream disconnected before completion.This suggests Remote Control recovery state may not be fully isolated by host and can leak into renderer/UI reconnect state for unrelated local conversations.
Raw logs are not attached because they contain conversation IDs, local paths, and remote host identifiers. I can provide a sanitized diagnostic bundle if maintainers specify the required fields.
joscar02ny-spec commentedon Sep 17, 2026
Additional bidirectional Mac-to-Mac reproduction with downgrade comparison
I can independently reproduce this exact failure between two Apple-silicon Macs using managed Remote Control in both directions. The controller logs contain both:
The host-side app-server remained alive through the events, with no matching app restart, orphan-worker event, sustained CPU alert, WLAN association loss, DNS failure, or general network interruption. The user-visible symptom is the connection indicator changing from green to yellow/red with “Reconnecting,” then recovering.
Version boundary
Both Macs previously ran desktop release
26.901.20858. Both were downgraded to the signed desktop release26.810.52044(bundle6662, bundled Codex CLI0.148.0-alpha.9) and held there for comparison.The downgrade materially reduced the defect but did not eliminate it:
The initial clean interval after both Macs matched the older build was 13.10 hours in one direction and 8.39 hours in the other. For Mac B → Mac A, median recovery improved from 6.207 s to 3.902 s and the longest observed recovery improved from 174.887 s to 4.376 s. Every post-downgrade true sequence-gap recovery completed within 4.4 seconds.
The post-downgrade window still contained two
stream became unknowncloses. One coincided with an intentional host app restart; the other did not, which provides another instance of an active stream becoming unknown while the remote app-server stayed running.Interpretation
This strongly matches the relay stream sequence/resume problem described in this issue. The version comparison suggests that a newer desktop release significantly amplified the frequency and recovery severity, while the underlying sequence-gap defect also exists in
26.810.52044. It does not correlate with local DNS, WLAN, host process death, version skew between the two Macs, or resource exhaustion.Raw logs are not attached because they contain task IDs, local paths, and device identifiers. Sanitized timestamped excerpts can be supplied if a maintainer specifies the fields needed.
Mark-RE-Johnson commentedon Sep 23, 2026
Additional Mac-to-Mac reproduction on desktop 26.917.51856 (10492)
Both controller and host run macOS 27.0 and ChatGPT/Codex desktop 26.917.51856 (10492). Both desktop apps and their bundled app-server processes were restarted before these tests. The same symptoms previously occurred on 26.915.31945 (9922).
I regularly see the brief “Connection to [host] was lost. Reconnecting...” banner both at home and away, approximately 5–6 times daily, sometimes more. That frequency/location is my observation, not a controlled count. The captured sequence-gap closures below corroborate recurrence outside the deliberate roaming tests.
Recent brief disconnect — 23 September 2026, UTC
remote control app-server stream sequence gap detectedETIMEDOUTinnode:netThat close-to-connected interval is about 15.8 seconds. The controller logs contain five explicit sequence-gap closures between 00:00 and approximately 08:18 UTC on 23 September. This is not claimed to equal the number of visible banners; sleep/idle/network state was not correlated for every event.
Reconnect stalls and submission failures — 22 September 2026, UTC
A controlled Wi-Fi → hotspot → Wi-Fi test used an existing remote Git project and the same read-only hostname/Git-root request. The host remained at home. Tailscale stayed enabled.
On the hotspot leg:
Timed out waiting for MCP response to fs/createDirectory.turn/startsucceeds. I reported needing a retry or restart; the exact intervention was not recorded.On return to Wi-Fi, independent probes captured the network transition and recovery:
thread/attachment/listrequests and onethread/turns/listrequest did not return until 23:22:06.748–06.822, with reported durations of 57.988–58.152 seconds andqueueWaitMs=0.turn/startsucceeded at 23:22:09.690. Recovery on this leg was automatic. No sequence-gap close or filesystem timeout was captured on this return leg.A further Composer
fs/createDirectorytimeout occurred at 23:38:08.203, followed by a successful submission at 23:38:19.228. There were no queue-full, queue-expired or connection-close records in the captured 23:29–23:44 window. No further network change had been requested, but continuous network health at that instant was not measured.Scope and requested follow-up
These observations support a recurring Remote Control failure and additional request delay after basic connectivity recovers. They do not prove that every filesystem timeout shares the sequence-gap cause: on the hotspot leg the filesystem timeout precedes the gap, and the later timeout occurs without a captured gap or queue-rejection burst. Git corruption is not established.
Could the Remote Control team confirm whether this remains a known issue on this build, identify a specific fixed build if available, or provide a supported diagnostic procedure for correlating client/host/relay request receipt, dispatch, response and stream sequence/resume state?
Bounded original logs are retained privately. This comment deliberately omits raw logs, account/device/session identifiers, private paths, addresses and conversation content. Sanitized correlation fields can be supplied if maintainers specify what is needed. No in-app Feedback ID has been generated; this is the single submission of this evidence to the existing tracked issue.
cerodb commentedon Sep 29, 2026
Still reproducible on 2026-09-29 with Codex Desktop 26.924.22138 on macOS -> Pop!_OS Linux app-server 0.159.0. Updating/restarting Desktop and updating/rebooting the remote host did not resolve it.
Uploaded feedback thread:
01a0ed0b-2e9d-7e10-9c6d-1dde077d6d8c.Opening a remote chat with a large history and attachments reproduces the gap. The same error also occurred before opening that chat, so attachments are not established as the root cause.
Controlled reproduction (2026-09-29, UTC):
Both closures recorded
remote control app-server stream sequence gap detected, with the tracehandlePong -> closeForStreamReconnect. Linux logs independently corroborate both connection closures and new initialize requests approximately six seconds later.Queue saturation followed the first gap, rather than preceding it. Before the first closure there was no recorded full queue or expired request, only four client and two internal requests pending.
thread/items/listhad waited 34.1 s,thread/attachment/list13.3 s, and twoconfigRequirements/readcalls about 13.4 s.After reconnecting, Desktop had 70 pending requests; the queue hit its 64-entry limit, with roughly 20
account/readrequests among the rejected requests. This prolonged UI recovery beyond transport reconnection. Whether this congestion causes subsequent gaps is unproven.The available logs expose neither expected/received sequence counters nor pong contents or per-message server emission evidence. We cannot rigorously distinguish Desktop reception/processing, relay behavior, or remote app-server transport as the original source.
Please correlate telemetry with these timestamps and the uploaded feedback, and investigate both the initial sequence gap and the post-reconnect burst of account/history requests. If further diagnostics are needed, please advise how to capture sequence counters without chat payloads or credentials.
chasewang0718 commentedon Oct 3, 2026
Additional Windows-to-Windows reproduction on 26.930.3930.0 (2026-10-03)
We observed the same error signatures on native Codex Remote between two Windows devices. This is corroborating symptom-level evidence, not proof that all reports share a root cause.
Environment and impact
Verified controller-to-host event, UTC on 2026-10-03
app_server_connection.closed, code4000, reasonremote control app-server stream became unknown; connected -> errorClose-to-connected duration: 2.253 seconds, calculated on the same client clock. These lifecycle entries represent one disconnect. This is a normalized excerpt verified against the original logs, not an unmodified raw log attachment.
Bounded passive measurements
Approximately 20 minutes of normal workload produced 239 laptop samples and 240 desktop samples. Traffic values are approximately 5-second network-adapter averages, not Codex-specific traffic.
The laptop main app process remained present throughout all samples. No app restart was observed on that device. CPU observations did not establish overload as the cause.
A larger traffic burst followed recovery; its cause is unknown. The sampled pre-event traffic does not support sustained local bandwidth saturation as the trigger for this occurrence. It cannot exclude shorter bursts, upstream congestion, or proxy/relay issues. Gateway probes only measure the local network. Wi-Fi negotiation rates were not treated as internet capacity. Cross-host timestamps use UTC but clock offsets were not independently measured.
Separate reverse-direction event
The Netherlands desktop's connection to the laptop closed at 08:11:28.132 UTC with code
4000, reasonremote control app-server stream sequence gap detected, and reconnected at 08:11:30.398 UTC (2.266 seconds). It is a separate event, not another count of the controller-to-desktop unknown-stream closure above.Capture validation and limits
The desktop collector initially used an invalid date path for incremental event collection. The complete capture window was subsequently re-read directly from original logs using shared file access; network/process samples were unaffected. Empty incremental event output was not interpreted as absence of disconnects. No relay/server trace was available, and the logical stream-close message alone does not prove an underlying WebSocket or physical network failure.
Could maintainers correlate these timestamps with stream lifecycle/resume and sequence handling, and advise whether there is a supported diagnostic procedure to capture the missing sequence/pong correlation without message payloads or credentials? Is there any documented native Remote throughput/concurrency limit relevant to this behavior? Less disruptive notification behavior during a short successful reconnect would also help.
Bounded original logs are retained privately; this comment omits raw logs, email/account/device/session identifiers, IP addresses, private paths and project/conversation content. No configuration change or connection repair was performed, and passive monitoring has ended. No in-app feedback/session ID was generated. The official Help Center AI support received the report but stated it could not create an engineering ticket or case ID, and directed us to this issue tracker.
jamiwe-dev commentedon Oct 10, 2026
Update: recurrence on October 10, 2026, with network and SSH comparison
This is an update from the original reporter's environment. The Remote Control sequence-gap resets still occur with current installed versions. I want to identify the failing component and a supported way to prevent the interruptions without stopping running tasks.
Environment
Recent Remote Control resets
All timestamps below are UTC on 2026-10-10. These are connection state transitions, not counts of repeated renderer error messages.
The recurring close reason is
remote control app-server stream sequence gap detected, with close code 4000. IONOS did not have simultaneous resets in the last two examples. The two running Ubuntu tasks were still reported as active/inProgress with no turn error at the subsequent checks.Selected diagnostic fields, reconstructed from logs with account, host and conversation identifiers omitted:
Several intervals between Ubuntu resets were approximately 34 minutes; the last two above were 34 min 27.302 s apart. This is an observation, not proof of a token or timer-related cause.
Some resets closely followed controller enrollment/token refresh. For example, refresh finished at 19:35:47.726 and the gap occurred 2.781 s later. A scan through 19:35 found 6 of 23 host sequence-gap closes within 10 s of a preceding refresh completion, with 14 refresh completions logged. Other gaps did not show this close relationship. Please treat this as correlation, not an established root cause.
Network and independent SSH comparison
I switched from Wi-Fi/DSL to a phone hotspot and later returned to Wi-Fi/DSL. The longer observation window contained both networks and cannot be treated as a controlled hotspot-only comparison.
configRequirements/readlatency was 18.28 ms on Ubuntu and 22.12 ms on IONOS.The SSH app-server probes used isolated stdio servers and read-only requests; they did not start turns or attach to the running tasks. These results do not establish the stability of the Desktop Remote SSH path itself. They also cannot exclude transient relay-path faults.
Migration and stale-host requests
Enabling SSH and disabling the old Remote Control connections did not migrate the existing chats' host association. Project/chat visibility changed, tasks appeared disconnected, and an attempted project reassignment failed with
The sidebar task belongs to a different host. Restoring Remote Control restored access to the existing running tasks.Requests targeting the disabled SSH identity continued for a time. Selecting Local in an empty new-task composer reduced generic metadata requests. Archiving and subsequently deleting three stale tasks removed their remaining polling. No further stale SSH-host requests were found after 19:08:38 in the inspected window, but Remote Control sequence-gap resets still occurred afterward. Thus stale task polling was not sufficient to explain or eliminate those resets.
Related GitHub reports and change
Requested investigation
No credentials, IP addresses, account/environment identifiers, project paths, task contents or raw log files are included in this update.
hd2210 commentedon Oct 12, 2026
I can reproduce what appears to be the same Remote Control streaming/synchronization issue in a Mac-to-Mac setup.
Environment
26.1007.30912on both MacsSymptoms
This is reproducible and significantly affects long-running tasks.
Diagnostic findings
I examined both the Codex app-server SQLite logs and the Codex Desktop application logs.
The client-side Desktop logs contain repeated occurrences of:
SEQUENCE_GAPUNKNOWN_CONVERSATIONTRANSPORT_CLOSEDCONNECTION_FAILEDWEBSOCKET_ERROR4000There were multiple clusters of sequence-gap errors, along with repeated WebSocket and transport failures.
The Rust-side app-server logs also showed intermittent remote-control WebSocket disconnections, including:
And reconnection failures such as:
These Rust-side connection errors were observed on the MacBook Air, although they may relate to its own Remote Control host connection rather than the client-side subscription to the Mac mini.
Troubleshooting performed
26.1007.30912).Suspected issue
The behavior suggests that the remote event stream may be interrupted or develop a sequence gap, and the client does not reliably recover its live subscription afterward.
The fact that reopening the session immediately restores the complete output suggests that the host-side execution and persisted conversation state remain intact, while the client-side live synchronization becomes stale.
I cannot yet determine whether the initial interruption is caused by the network/proxy or the Remote Control transport itself. However, the failure to recover live updates appears to be an important part of the issue.
Expected behavior
Remote Control should automatically reconnect, recover any missing events, and continue streaming new output without requiring the user to manually leave and reopen the session.
Is this a known issue in build
26.1007.30912? Are there any workarounds or additional diagnostics that would help identify why live event synchronization fails to recover?I can provide additional sanitized logs or perform targeted tests if needed.