Skip to content

Codex desktop repeatedly disconnects mid-task with “Reconnecting” and “error sending request” #51580

Open
Open
Codex desktop repeatedly disconnects mid-task with “Reconnecting” and “error sending request”#51580
Labels
appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

Description

@habbylabby737
habbylabby737
opened on Oct 7, 2026

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

26.930.61225 (build 13232)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 27.0.1, Apple silicon — uname -mprs: Darwin 27.0.0 arm64 arm

What issue are you seeing?

During a long-running local coding task, the response stream repeatedly disconnected. The chat displayed “Reconnecting 1/5” and “Reconnecting 2/5” entries. Opening the error details showed these messages:

stream disconnected before completion: error sending request

stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID a4d0f034-62f2-4ebd-ae3b-a9274e49b3c4 in your message.

Work sometimes continued afterward, but the disconnect/reconnect errors recurred within the same session. I have not established whether the cause is the client, network transport, or service.

Observed workflow

  1. Open an existing local project chat in the desktop app.
  2. Ask the agent to continue a coding task involving file edits, command execution, and inspection of rendered images.
  3. Let the task run for several minutes.
  4. Observe repeated “Reconnecting” entries and a “stream disconnected before completion” error during the active run.

These are the steps from the affected workflow, not a guaranteed minimal reproduction. The app-provided Feedback ID is in the reproduction field below.

What steps can reproduce the bug?

Feedback ID: 01a10fe4-f300-7e10-9f43-5c7bb35c629c

What is the expected behavior?

The active task should complete without repeated stream disconnections. If a connection drops temporarily, the app should reliably resume the response while preserving completed work, or clearly report that the run failed and provide a usable retry path.

Additional information

The app’s built-in feedback flow confirmed “Feedback submitted” and opened this Codex App issue template with the Feedback ID above.

The installed macOS app is currently branded ChatGPT (bundle identifier: com.openai.codex). The version and build above were verified from the installed app bundle.

This public report intentionally omits local usernames, file paths, project names, source code, account contact details, and unrelated browser activity. No raw logs or screenshots are attached.

Activity

  1. habbylabby737
    added
    appIssues related to the Codex desktop app
    on Oct 7, 2026
  2. github-actions
    added
    bugSomething isn't working
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Oct 7, 2026

  3. github-actions commented on Oct 7, 2026

    @github-actions
    github-actionsbot
    on Oct 7, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  4. STREALOK commented on Oct 8, 2026

    @STREALOK
    STREALOK
    on Oct 8, 2026 – with ChatGPT Codex Connector

    Additional Windows observation — 8 October 2026

    I am adding this to the existing report because the visible symptom overlaps; I have not established a shared cause with the macOS report.

    Environment snapshot: Windows 10 Pro 10.0.19045 x64; app 26.1002.52244, build 13536, prod. The app update API returned up_to_date in the result recorded at 13:00 UTC; this concerns the configured updater, not every release channel. Separately, the known running core reported codex-cli 0.162.0-alpha.2 at 13:05:50 UTC. Neither snapshot establishes an exact build at an earlier screenshot capture time.

    (Related (and installed) / Used) Runtimes & Redists: the dated SDK/Node, bundled VC DLL and installed-VC registration inventory is in the environment follow-up. Those file/registration observations do not establish which libraries the reconnect transport loads. Its loaded-runtime identity remains unknown here.
    Observation: During an active local workflow involving source reads, command requests and file edits, the user supplied two UI captures showing repeated Reconnecting progress. One shows 2/5; the other shows 3/5, 3/5, 3/5, 4/5, 3/5, 2/5 interleaved with tool activity. These are displayed progress entries, not a measured count of independent outages. The exact capture times and retry durations are unknown.

    Partial reproduction description: Continue an existing local task involving file and command operations; in the affected run, the progress entries recur while the task continues. This describes the observed workflow, not a reliable initiating trigger or clean-state reproduction. I have not established the exact transport error/request ID for these captures and am not borrowing the other reporter's errors.

    Effects checked: Selected saved source files and mutation receipts were subsequently read back and matched their recorded hashes. This does not prove every response, unsaved state or interrupted operation survived. Workflow loss and the cause remain unverified.

    The same installation also has a separately reported Windows sandbox runtime ACL-open sharing failure: #51861. A causal relationship between that fault and these reconnects is UNKNOWN.

    Useful diagnostic improvements would be a timestamped connection/retry event ID, a clear final outcome for the interrupted operation, and a distinction between stream recovery and local executor setup failure. This is an engineering proposal, not an identified implementation cause or tested fix.

    Private project names, paths, account details, transcripts and raw UI captures are omitted. No desktop automation, deliberate network disruption, usage exhaustion or app/process restart was performed for this observation.

  5. yoshiwo3 commented on Oct 10, 2026

    @yoshiwo3
    yoshiwo3
    on Oct 10, 2026 – with ChatGPT Codex Connector

    Additional Report — Repeated Stream Disconnections During Codex Desktop Development Tasks (October 10, 2026)

    I am experiencing repeated stream disconnected before completion errors in Codex Desktop, preventing me from reliably continuing an existing software development task.

    I have already submitted diagnostic feedback through the application's built-in feedback feature.

    Feedback ID:
    01a02809-f0b0-7633-a3b9-55a3d0ca6cba

    Environment

    • Product: Codex Desktop
    • Date: October 10, 2026
    • Time: Approximately 21:29–21:32 JST (UTC+9)
    • OS and application version: Not yet confirmed

    Observed Behavior

    1. The application repeatedly displayed reconnection attempts followed by stream disconnected before completion.
    2. After I instructed Codex to resume the interrupted task, processing resumed temporarily but failed again.
    3. The interface displayed messages indicating that commands had been executed and files had been edited, even while connection errors continued.
    4. After I explicitly instructed Codex to stop, the assistant acknowledged the stop request and stated that it would preserve uncommitted changes without starting further implementation, testing, or commits.
    5. However, another "Command executed" indicator and a reconnection message appeared afterward.

    The UI events alone do not establish whether commands continued executing after the stop request or whether previously completed events were displayed late.

    Related Request IDs

    • 41ea4e6c-ed28-4498-9bcf-b0df2c180955
    • 8ebe073d-9c52-4c23-9f87-283a83d534f6
    • 20ebcb8f-6504-4a84-865a-99cb225691fb
    • 4a754ae9-7f3c-4651-8e14-e71c4b8ba9ba
    • 5e7b05ed-38bf-444b-8e25-d23629dfd215
    • c32569f4-edc5-4441-ae20-c22326712d85

    Impact

    These repeated failures are disrupting ongoing development.

    Because file modifications and command executions may have completed despite the streaming errors, blindly retrying the task could cause duplicate operations or inconsistent project state.

    Preserving the original conversation, working files, and uncommitted changes is important.

    Request for Engineering Investigation

    Could the Codex engineering team please:

    1. Correlate the submitted Feedback ID with the Request IDs and investigate the actual cause of the repeated streaming failures.
    2. Determine whether the failures originate from the desktop client, network transport, session recovery, or backend processing.
    3. Verify whether commands continued executing after the explicit stop instruction, or whether the UI displayed delayed events.
    4. Clarify which file modifications and command executions were successfully completed before each disconnection.
    5. Provide a supported method to safely resume the existing task without losing or duplicating work.

    I have contacted OpenAI's help center, but the AI support assistant could not access the diagnostic logs or establish the root cause.

    I understand that network-related WebSocket interruptions are one possible explanation, but no root cause has been confirmed for this incident.

    I would appreciate an engineering investigation based on the submitted diagnostics rather than another round of generic network troubleshooting.

    Thank you.

  6. hannival23 commented on Oct 15, 2026

    @hannival23
    hannival23
    on Oct 15, 2026

    Additional report from Windows: repeated "Reconnecting" during an active local task.

    The user reports that the desktop UI repeatedly shows the Korean equivalent of "Reconnecting" and progress is frequently interrupted. This occurs while continuing an existing local task involving command execution and image inspection. Some commands and file writes still complete. This is an observed workflow, not a reliable minimal reproduction.

    Environment:

    • Windows x64, Korean UI
    • Bundled Codex CLI: 0.162.0-alpha.17.2
    • Exact desktop app version was not verified; the CLI version above is not asserted to be the desktop app version.
    • Observed on October 15, 2026 (Asia/Seoul)

    Selected desktop log events (timestamps UTC; identifying fields omitted):

    2026-10-15T00:15:12.924Z [tpp-local-executor] Local Work executor rendezvous unavailable attempt=2 outcome=disconnected reason=peer_close
2026-10-15T00:15:14.286Z [tpp-local-executor] Local Work executor rendezvous unavailable attempt=2 outcome=error reason=websocket_error
2026-10-15T00:35:39.716Z [AppServerConnection] app_server_connection.closed code=1006 failureReason=unknown transport=websocket
2026-10-15T01:48:19.541Z [tpp-local-executor] Local Work executor rendezvous unavailable attempt=2 outcome=disconnected reason=peer_close
2026-10-15T01:48:20.234Z [tpp-local-executor] Local Work executor rendezvous unavailable attempt=2 outcome=error reason=websocket_error
2026-10-15T01:51:14.390Z [AppServerConnection] app_server_connection.closed code=1006 failureReason=unknown transport=websocket
2026-10-15T03:18:53.791Z [AppServerConnection] app_server_connection.closed code=1006 failureReason=unknown transport=websocket

    These events establish repeated transport disconnections but do not establish the cause, or prove that each event corresponds to a particular UI interruption. A shared root cause with the original report is unconfirmed. Network comparisons and a controlled reproduction have not been performed.

    Expected: reliably resume the active task and clearly distinguish reconnecting from a stalled or failed run, while preserving completed work.

    Posted by the assistant at the user's explicit request. No raw logs, session transcript, source code, images, account contact details, private paths, or conversation identifiers are attached.

  7. nilsperssonsuorra commented on Oct 15, 2026

    @nilsperssonsuorra
    nilsperssonsuorra
    on Oct 15, 2026

    For anyone hitting this only in some long threads while new threads work fine: in my case (Windows 10, Codex Desktop 26.1007) it wasn't the network. It was request payload size from inline images. Rendered images viewed in the thread plus images carried through compaction added up to ~160 MB uploaded per request, and the upload got cut off. That shows up as error sending request / Reconnecting.

    After shrinking the images in the rollout files, it dropped to ~10 MB/request. Measurements and the workaround are in #52456.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions