›_ Codex Issues
Codex Issues / #38055

[Windows][26.803.10989.0][SSH Remote] Send stalls with a 5–6 GB memory spike and delayed queued/Steer delivery; ~100 KB attachments can crash

Open 💬 5 comments Opened Aug 11, 2026 by OlegKnyaginin
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.803.10989.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex Desktop 26.803.10989.0 on Windows becomes unreliable when sending messages to an SSH remote.

There are two related failure modes:

  1. A plain-text message enters an ambiguous delayed-delivery state. Memory rises to approximately 5–6 GB and later falls to approximately 4 GB. The Send button becomes available again, and a subsequent Send interaction displays the message as queued with a Steer action. The message is temporarily absent from the same conversation on Android, but after restarting the Windows app it is eventually delivered and begins processing.
  1. Sending two small local text attachments, approximately 100 KB combined, can make memory reach approximately 10 GB and cause the entire application to exit silently.

Both behaviors reproduce after a complete reset of the local Windows Codex profile and Microsoft Store/MSIX application data.

Environment

  • Codex Desktop / Microsoft Store package: OpenAI.Codex 26.803.10989.0
  • Architecture: x64
  • Platform: Microsoft Windows NT 10.0.26200.0 x64
  • Subscription: ChatGPT Pro
  • Target environment: SSH remote
  • The same SSH remote and conversations are accessible and usable through ChatGPT on Android

Failure mode 1: plain-text message, memory spike, and delayed queued delivery

I opened a conversation associated with an SSH remote and sent a simple plain-text message with no attachments.

Observed sequence:

  1. I clicked Send.
  2. The Send button became disabled.
  3. The turn did not visibly enter Thinking or Reasoning.
  4. The ChatGPT/Codex process group increased to approximately 5–6 GB of memory.
  5. Memory later fell to approximately 4 GB.
  6. At approximately the same time, the Send button became available again.
  7. I clicked Send again.
  8. The message then appeared in Windows Desktop with a Steer action, as if it had been queued behind an active turn rather than submitted normally.
  9. I opened the exact same conversation through ChatGPT on Android.
  10. At that moment, the message displayed by Windows was absent from the Android conversation.
  11. I later closed and reopened ChatGPT/Codex on Windows.
  12. After reopening the app, the previously queued message appeared in the conversation and began processing.
  13. I clicked Stop, and the Stop action was accepted.

The message was therefore not permanently lost. Instead, the Windows client temporarily provided no reliable indication of whether the message had been:

  • accepted by the remote;
  • locally queued;
  • committed to the shared conversation;
  • waiting to steer an existing turn;
  • or still pending submission.

The plain-text case does not produce continuously unbounded memory growth. Memory rises to approximately 5–6 GB and then decreases to approximately 4 GB. However, the submission, queue, and active-turn state remain ambiguous until the application is restarted.

This behavior creates a duplicate-execution risk. While Windows makes the original message look unsent or merely queued, the user may resend the same instruction from Windows or Android. The original message may then be delivered later.

Failure mode 2: small text attachments cause high memory use and silent exit

I also reproduced a more severe failure with two small local text files, approximately 100 KB combined.

Reproduction where both attachments completed uploading

  1. I opened a conversation on the same SSH remote.
  2. I attached the two text files.
  3. Both files appeared to complete uploading.
  4. I clicked Send.
  5. The turn did not visibly enter Thinking or Reasoning.
  6. Application memory increased to approximately 10 GB.
  7. The entire Windows application then exited silently.

Reproduction with Troubleshooting performance recording enabled

After a full Windows restart:

  1. I enabled the built-in Troubleshooting performance recording.
  2. I attempted to attach the same files.
  3. The first attachment completed.
  4. The second attachment remained stuck during attachment/upload processing.
  5. Application memory reached approximately 5–6 GB.
  6. I stopped the performance recording before allowing the application to reach another 10 GB failure.
  7. I attempted to submit or preserve the trace, but I could not confirm whether it was successfully uploaded because the application exits before displaying a reliable confirmation.

No feedback/session ID was displayed, so the trace submission status is unknown.

Clean-profile isolation

Before the final reproduction, I performed a complete local Windows profile reset:

  1. Backed up and disabled the previous Windows %USERPROFILE%\.codex directory.
  2. Backed up the Microsoft Store application profile.
  3. Reset the OpenAI.Codex MSIX application data.
  4. Restarted Windows.
  5. Signed into the application again.
  6. Did not restore the old config.toml.
  7. Did not restore the previous plugins, MCP configuration, or cached local state.
  8. Added the SSH connection again.
  9. Added the remote projects again.
  10. Reproduced the attachment failure in the previous conversation.
  11. Reproduced the plain-text submission problem in another conversation.

The issue therefore does not appear to be caused by:

  • the previous local .codex profile;
  • the old config.toml;
  • old plugin or MCP settings;
  • cached MSIX application data;
  • one specific conversation;
  • or the attachment files alone.

The same SSH remote continues to work through ChatGPT on Android, which suggests that the remote host and remote project are functional and that the failure is specific to the Windows Desktop client or its SSH remote message/turn synchronization path.

Diagnostics

  • Troubleshooting performance recording was enabled during one attachment reproduction.
  • The recording was stopped before another high-memory crash.
  • Trace submission status is unknown.
  • No feedback/session ID was shown before the application exited.
  • No relevant Codex Windows Error Reporting event was found for the latest silent exits on 26.803.10989.0.
  • A RADAR_PRE_LEAK_64 event found for firefox.exe was unrelated and is not part of this report.

A performance trace may exist in the backed-up local application data. I can provide it through a secure/private channel if requested by a maintainer and if it can be located and reviewed for private content.

Possibly related issues

These appear related but are not exact duplicates:

  • #37829 — Windows renderer memory growth and hang on package 26.803.5235.0
  • #24287 — Desktop accepts a prompt but loses reliable turn/stream state; resent prompts may later appear as steered continuations
  • #35207 — cross-device queue and active-turn state desynchronization

What steps can reproduce the bug?

Plain-text delayed-delivery reproduction

  1. Install or update Codex Desktop for Windows to 26.803.10989.0.
  2. Add a working SSH remote.
  3. Open a conversation associated with a project on that SSH remote.
  4. Enter a simple plain-text message with no attachments.
  5. Click Send.
  6. Observe that:
  • Send becomes disabled;
  • the turn does not visibly enter Thinking or Reasoning;
  • application memory rises to approximately 5–6 GB.
  1. Wait until memory falls to approximately 4 GB and Send becomes available again.
  2. Click Send again.
  3. Observe that the message appears with a Steer action, as if queued behind an active turn.
  4. Open the exact same conversation through ChatGPT on Android.
  5. Observe that the message is not yet visible there.
  6. Close and reopen ChatGPT/Codex on Windows.
  7. Observe that the previously queued message is eventually delivered and begins processing.
  8. Click Stop.
  9. Observe that Stop is accepted.

Attachment crash reproduction

  1. Open a conversation associated with the SSH remote.
  2. Attach two local text files with a combined size of approximately 100 KB.
  3. Wait for the attachments to complete uploading.
  4. Click Send.
  5. Observe that the turn does not visibly enter Thinking or Reasoning.
  6. Observe memory increasing into multiple gigabytes, in one reproduction reaching approximately 10 GB.
  7. The Windows application exits silently.

What is the expected behavior?

A single click on Send should immediately produce an authoritative and visible state:

  • submitted and running;
  • explicitly queued behind a real active turn;
  • or failed with an actionable error.

The Send button must not become available again while the original submission may still be pending or capable of being delivered later.

Windows Desktop and Android should converge promptly on the same message, queue, and active-turn state.

Restarting the Windows app should not be required to make a previously submitted message appear and begin processing.

Memory usage should remain bounded during submission and synchronization.

Additional information

This issue currently makes Windows Desktop unsafe and unreliable for SSH remote work.

The ambiguous delivery state can cause users to resend prompts that were already accepted or recoverable. If those prompts modify files, create commits, deploy software, delete data, or perform other external actions, delayed duplicate delivery may cause conflicting or repeated operations.

Windows Desktop is specifically needed in this workflow to attach local files to remote conversations. The immediate workaround is to:

  • upload files separately through SCP or SFTP; and
  • control the same remote conversation through ChatGPT on Android.

However, this workaround is not operationally equivalent in all workflows.

For example, I have developed a complex safety-sensitive procedure whose reviewed execution plan explicitly requires files to be attached through the Windows Desktop client at defined stages. Replacing that attachment path with SCP/SFTP and mobile control changes the procedure itself. I therefore cannot safely assume that the modified workflow preserves the same guarantees without revising the plan and repeating its independent reviews.

That would require substantial additional time and paid model usage, even though neither the underlying task nor the files have changed. More generally, users with reviewed, audited, or tightly specified agent workflows may not be able to substitute a different transport path without revalidating the entire procedure.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 16 days ago

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

  • #37584

Powered by Codex Action

OlegKnyaginin · 15 days ago

Related, but I do not believe this is an exact duplicate.

#37584 reports a broader renderer memory leak / UI-backend desynchronization on Desktop build 26.803.41515 / MSIX package 26.803.5235.0, including stuck Thinking states, project threads that never load, and silent exits.

My report reproduces on the newer MSIX package 26.803.10989.0, after a complete reset of the local Windows Codex profile and application data, and includes a more specific SSH-remote message lifecycle failure:

  • a plain-text Send causes memory to rise to approximately 5–6 GB and later fall to approximately 4 GB;
  • Send becomes available again even though the original message may still be pending;
  • the message is displayed as queued with a Steer action;
  • it is temporarily absent from the same conversation on Android;
  • after restarting the Windows application, the message is eventually delivered and starts processing;
  • two small text attachments, approximately 100 KB combined, can increase memory to approximately 10 GB and cause a silent app exit.

The two reports may share the same underlying renderer/app-server synchronization defect, but the delayed queued/Steer delivery, cross-client state disagreement, SSH-remote context, attachment trigger, and reproduction on the newer build are not described in #37584.

I am happy for maintainers to link or consolidate the reports if they confirm that the root cause is the same.

likemoonriver · 14 days ago

I can reproduce a very similar issue on Windows 11 Pro with ChatGPT/Codex Desktop build 26.803.10989.0, specifically when using an SSH Remote project.

The behavior is highly reproducible for me:

  • Regular Chat in the same Windows app works normally.
  • SSH connectivity to the remote server itself is normal.
  • In a Codex SSH Remote project, the first message often completes normally.
  • The second or third message frequently gets stuck in the sending/working state, sometimes for several minutes.
  • Some stuck requests eventually return a result after a long delay.
  • In at least one case, a task that had appeared stuck before restarting the computer later showed a complete result after restart.
  • Restarting only the ChatGPT app has not reliably fixed the problem.
  • Earlier, restarting the proxy client sometimes temporarily restored responsiveness, but the problem returned after a few requests.

I also measured the total working set of all ChatGPT.exe / codex.exe processes during a clean reproduction:

Freshly started app:                       1.42 GB
After one normal Chat message:             1.81 GB
After first SSH Remote reply:              2.99 GB
Second Remote request starts spinning:     3.76 GB
After that request eventually completes:   3.43 GB

Third Remote request starts spinning:      4.17 GB
While still spinning:                      4.88 GB
                                           4.71 GB
                                           4.40 GB
                                           4.27 GB
Peak while still spinning:                 5.15 GB
Later while still spinning:                ~4.7 GB

So the memory usage is not strictly monotonic, but entering the stuck Remote state is consistently associated with a large increase in memory and significant CPU activity in multiple ChatGPT.exe processes.

I also checked whether the delay was caused by work still running on the remote server. During one long “Working” state, there was no matching Rscript / analysis process running on the server, while the Desktop app continued spinning.

Network troubleshooting already performed

I tried to rule out a simple proxy/node/connectivity problem:

  • Tested both Clash for Windows and Clash Verge Rev / Mihomo.
  • Tested multiple US nodes and a Singapore node.
  • Tested System Proxy and TUN configurations.
  • Regular Chat remained usable.
  • SSH Remote connectivity itself remained usable.
  • Direct proxy tests to OpenAI endpoints were fast and successful:
https://chatgpt.com/
TLS ~1–1.7 s, request completed

https://ws.chatgpt.com/
TLS ~0.5–2 s, request completed
  • Windows Firewall shows no outbound block rule for ChatGPT/Codex.
  • Temporarily disabling 360 security software did not help.
  • Explicit HTTP_PROXY / HTTPS_PROXY environment variables did not solve it.
  • I also tested an HTTP-only custom provider with supports_websockets = false; the first request worked, but the second request again became stuck.

The local Codex logs also contain entries involving:

codex_api::endpoint::responses_websocket
codex_core::session::session        websocket, timeout
codex_core::responses_retry         stream disconnected, websocket, connection closed
codex_api::sse::responses

and I have seen the UI error:

stream disconnected before completion:
error sending request for url
(https://chatgpt.com/backend-api/codex/responses)

Additional observation

The issue started immediately after recent updates on my machine. The ChatGPT Store app was updated on 2026-08-11, and Windows also installed updates the night before I first noticed this behavior. I cannot determine whether either update is causal, but the timing may be relevant.

Overall, my reproduction looks very similar to the reported SSH Remote message lifecycle / renderer-app-server synchronization issue:

first request works → later Remote request stalls → memory rises to ~4–5+ GB → request may eventually appear/complete after a long delay or restart.

I am happy to provide additional logs or run specific diagnostics if that would help isolate the issue.

likemoonriver · 14 days ago

I did a more detailed follow-up investigation and found a workaround that has, so far, restored normal SSH Remote behavior.

Environment

  • Windows ChatGPT/Codex Desktop: 26.803.10989.0
  • Windows x64
  • ChatGPT Pro
  • Remote host: Linux over SSH
  • Remote Codex before troubleshooting: 0.144.1
  • Remote Codex after troubleshooting: 0.147.0

Original behavior

The issue was reproducible specifically in SSH Remote projects.

Normal Chat and projects using a local Windows directory continued to work normally.

In an SSH Remote project, the first one or two messages could succeed, but after approximately 2–3 turns the next message would often remain pending/spinning indefinitely.

At the same time, several local ChatGPT.exe processes showed substantial CPU and memory growth.

For example, during one stalled period:

PID       RAM_MB   CPU_s
11912       899     759.0
20092      1128    1304.5
22184       758    1114.4

A few samples later, while the UI was still stalled:

11912      1053     887.5
20092       696    1539.6
22184       666    1308.9

Process inspection showed that the high-load processes included the Electron/Chromium renderer processes:

20092  ChatGPT.exe --type=renderer
22184  ChatGPT.exe --type=renderer
11952  ChatGPT.exe --type=gpu-process
11912  main ChatGPT.exe process

Importantly, the remote server was not overloaded at the same time:

codex app-server proxy   ~2.1% CPU
codex app-server         ~2.0% CPU
codex-code-mode-host      0.0% CPU

Running Codex CLI directly on the same remote server was also usable, so this did not look like a basic SSH, network, or remote compute-capacity problem.

Port-forwarding/authentication checks

I also found an old Bitvise C2S forwarding rule:

127.0.0.1:1455 -> 127.0.0.1:1455

Bitvise was reporting repeated connection-refused errors for this forwarding rule.

I disabled the rule. The Bitvise errors disappeared, but the SSH Remote pending/high-CPU problem later reproduced, so this forwarding rule was a real configuration issue but does not appear to be the main cause of the performance problem.

There was also a separate remote authentication issue (refresh token was revoked) during troubleshooting. However, fixing/re-establishing the remote authentication path did not by itself permanently eliminate the Remote UI stalls.

Important finding: the remote app-server was very old and long-lived

The remote host had this process:

PID 2346495
codex -c features.code_mode_host=true app-server --listen unix://
ETIME: ~32 days

with a child:

codex-code-mode-host
ETIME: ~31 days

The remote Codex/app-server version was 0.144.1.

After upgrading the remote Codex installation:

codex-cli 0.147.0

I initially got:

{
  "managedCodexVersion": "0.147.0",
  "cliVersion": "0.147.0",
  "appServerVersion": "0.144.1"
}

So the CLI had updated, but the already-running SSH Remote app-server was still the old 0.144.1 process.

codex remote-control stop could not stop it:

Error: app server is running but is not managed by codex app-server daemon

Workaround performed

I then:

  1. Fully exited the Windows ChatGPT/Codex Desktop app.
  2. Confirmed that the SSH-side codex app-server proxy process exited.
  3. Gracefully terminated the remaining old ~32-day 0.144.1 app-server.
  4. Confirmed that no Codex/app-server processes remained.
  5. Confirmed that the current remote Codex binary now pointed to 0.147.0.
  6. Reopened the Windows Desktop app and reopened the same SSH Remote project.
  7. Allowed Desktop to create a completely new Remote app-server/proxy.

The newly created processes had fresh PIDs/uptime, and the new proxy binary was confirmed to come from the 0.147.0 installation.

Result after rebuilding the Remote backend

The behavior changed substantially.

I first sent approximately 9–10 consecutive lightweight requests. All completed normally.

Total local ChatGPT.exe working set was approximately:

1.59 GB
1.60 GB
1.64 GB
1.66 GB
1.63 GB
1.70 GB
1.78 GB

instead of the roughly 3.0–3.5 GB seen during the previous stalled state.

I then left the SSH Remote project open and idle for about 10 minutes.

Total ChatGPT working set remained approximately:

1.69 GB
1.59 GB
1.64 GB
1.58 GB
1.58 GB

One renderer-like process changed as follows:

508 MB
406 MB
424 MB
400 MB
401 MB

so memory was clearly being reclaimed rather than increasing monotonically.

CPU accumulation also slowed substantially during idle periods.

Real-workload test

I then resumed actual work in the same SSH Remote project, including:

  • reading project files,
  • inspecting scripts,
  • creating/editing analysis scripts,
  • running lightweight commands,
  • multi-turn discussion,
  • some single-cell analysis work.

So far, responsiveness has remained close to normal.

During real use, total ChatGPT working set increased from roughly 1.6 GB to a temporary peak around 2.0 GB, then decreased again and stabilized around 1.8–1.9 GB.

I have not reproduced the previous pattern of:

pending/spinning UI
+
rapid renderer CPU accumulation
+
~3–3.5 GB local ChatGPT memory

after rebuilding the Remote backend.

Current interpretation

I do not think the evidence is sufficient to say that 0.147.0 alone fixes the issue.

Two related variables changed together:

remote Codex/app-server 0.144.1 -> 0.147.0

and

~32-day-old Remote app-server -> completely fresh app-server

Therefore I cannot distinguish between:

  1. a compatibility/lifecycle issue in 0.144.1,
  2. accumulated bad state in a long-lived Remote app-server,
  3. or an interaction between both.

The Windows Desktop SSH Remote renderer/app-server/message lifecycle path may still be involved, because during the failure the heavy CPU/RAM activity was primarily on the Windows renderer side while the remote app-server remained lightly loaded.

However, the strongest practical correlation so far is that upgrading the remote Codex installation and fully rebuilding the long-lived SSH Remote app-server restored stable behavior.

Current workaround

For anyone seeing similar Windows SSH Remote stalls, a potentially useful diagnostic/workaround is:

  1. Update Codex on the remote host.
  2. Fully exit the Desktop app so the SSH app-server proxy disappears.
  3. Check whether an old Remote codex ... app-server --listen unix:// process is still running.
  4. If it is safe to do so and no task is active, terminate that old backend.
  5. Verify the remote current/codex points to the updated release.
  6. Reopen Desktop and let SSH Remote start a fresh app-server.
  7. Re-test before changing networking/authentication settings further.

I will continue using the same SSH Remote project under normal scientific workloads and report back if the pending/high-CPU behavior returns.

OlegKnyaginin · 13 days ago

I tested the workaround suggested above, and it restored normal SSH Remote behavior.

State before the workaround

The current Codex installation on the remote host was already up to date:

command -v codex
/home/<user>/.local/bin/codex

codex --version
codex-cli 0.147.0

However, the active SSH Remote backend had been running for approximately 32 days:

codex -c features.code_mode_host=true app-server --listen unix://
ETIME: approximately 32 days

Its child codex-code-mode-host was explicitly running from the older standalone release:

~/.codex/packages/standalone/releases/0.144.3-x86_64-unknown-linux-musl/bin/codex-code-mode-host

This explains why resetting the local Windows Codex profile and MSIX application data did not help: after reconnecting, Windows Desktop could still reuse the same long-lived remote backend.

Workaround performed

After confirming that no remote task was active, I:

  • Fully exited ChatGPT/Codex Desktop on Windows.
  • Sent SIGTERM to the old remote app-server process.
  • Confirmed that the old app-server, wrapper process, and code-mode-host exited cleanly.
  • Reopened the Windows Desktop application and the SSH Remote project.
  • Allowed Desktop to create a fresh remote app-server and proxy.

The new processes were started from the current 0.147.0 release:

~/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex
Result

After rebuilding the remote backend, the original workflow passed:

  • plain-text messages are sent normally;
  • the delayed queued/Steer state has not reproduced;
  • the same local text attachments now upload and send normally;
  • the application no longer grows to 5–10 GB during this workflow;
  • the application no longer exits during attachment submission.
  • Interpretation

This strongly associates the failure with the stale, long-lived SSH Remote backend.

However, two variables changed together:

  • the backend components moved from the older 0.144.3 release to 0.147.0;
  • the approximately 32-day-old backend state was replaced with a fresh process.

Therefore, this test does not distinguish between:

  • a compatibility issue involving the older remote backend;
  • accumulated bad state in a long-lived app-server;
  • or an interaction between both.

The issue is still relevant because Desktop did not detect or clearly report that the running remote backend was stale relative to the currently installed CLI. Ideally, Desktop should detect this version/lifecycle mismatch and offer or perform a safe backend restart instead of entering a multi-gigabyte memory spike, ambiguous message state, and silent exit.

I will continue using the same workflow and report back if the problem returns.