[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

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.

2. 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.
7. Wait until memory falls to approximately 4 GB and Send becomes available again.
8. Click Send again.
9. Observe that the message appears with a Steer action, as if queued behind an active turn.
10. Open the exact same conversation through ChatGPT on Android.
11. Observe that the message is not yet visible there.
12. Close and reopen ChatGPT/Codex on Windows.
13. Observe that the previously queued message is eventually delivered and begins processing.
14. Click Stop.
15. 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.

No source file or test is named. Start by reproducing the plain-text and attachment failures on Windows with an SSH remote, then inspect the desktop message/turn synchronization path and the available performance trace. Done means submissions have an authoritative visible state, messages converge across Windows and Android without restart, and memory remains bounded without a silent exit.