Windows desktop app: second/follow-up message hangs indefinitely in Work and Codex after Sep 5 update

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

26.901.51231

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I am experiencing a regression in the Windows ChatGPT desktop app where the first message in a Work or Codex conversation works, but the second/follow-up message stays processing indefinitely and never completes.
The issue appears to have started recently, likely after the latest Windows desktop app update.

What steps can reproduce the bug?

Feedback ID: no-active-thread-01a07a50-f278-7413-84ad-afebdb0420d9

Open the ChatGPT Windows desktop app.
Open an existing Work or Codex conversation, or create a new one.
Send the first message.
Wait for the response to complete.
Send a second/follow-up message in the same conversation.
The second message stays in a processing/loading state indefinitely.

What is the expected behavior?

The second and subsequent messages should send and receive responses normally, just like the first message.

Additional information

Troubleshooting already attempted:

Restarted the Windows laptop.
Uninstalled and reinstalled the ChatGPT desktop app.
Tested multiple different chats/projects.
Tested the same Work conversations in the browser.
Tested on the iPhone app.

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

Powered by Codex Action

Additional Windows report with a slightly different UI symptom that appears closely related to this regression.

Environment

Windows desktop MSIX package: 26.901.6511.0
Version reported by the app-server client logs: Codex Desktop 26.901.51231
Bundled codex-cli: 0.153.4
Windows x64

Symptom

Every previously completed local Codex chat opens with the composer/send button disabled (grey), so a follow-up message cannot even be submitted.
A newly created chat accepts its first message normally.
Restarting the app and terminating all ChatGPT.exe/codex.exe processes does not help.
The affected chats are not archived and are not waiting for approval; their backend status is idle or notLoaded, with completed turns and no stored turn error.

Reproduction

Create a new local Codex chat.
Send one message and wait for the turn to complete.
Navigate away and reopen that chat.
The composer is read-only and the Send button remains grey.

Local diagnostics

All affected user-created Codex threads inspected in state_5.sqlite have history_mode = paginated.
On reopening an affected chat, the desktop client emits thread/resume, but the composer remains disabled.
The local host/environment is available and new chats still work.
Current App Server documentation says existing paginated records may be listed/read as summaries, while full history reads, turn pagination, and resume are rejected until paginated history support is available. This matches the observed read-only history UI.

Expected behavior

Completed local chats should be resumable, and the composer should become enabled after thread/resume.

No session transcripts, workspace paths, account identifiers, or private logs are included here. I can provide sanitized diagnostics if maintainers need them.

I’m seeing the same issue after updating ChatGPT Desktop for Windows to 26.903.61454 on September 9, 2026.

The behavior is fully reproducible on my side:

Existing conversations: I can type a message, but the Send button stays disabled/gray. Clicking it only shows a spinner and the message is never submitted.
New conversations: the first message sends successfully, but after the assistant finishes responding, the second message cannot be sent.
This started immediately after the update.

I also checked the Desktop logs. In multiple conversations, the renderer restores the thread with:

latestTurnStatus=completed
markedStreaming=true

So the app-server considers the previous turn completed, while the Desktop UI still appears to treat the conversation as streaming/busy.

For a newly created conversation, the first message produces a normal:

method=turn/start

but after clicking Send on the second message, there is no subsequent turn/start in the log. This suggests the follow-up message is getting stuck in the Desktop UI / conversation state before reaching the local app-server.

I also saw:

Received turn/started for unknown conversation
Received turn/completed for unknown conversation

in the same session, which may be related to the conversation-routing/state-sync issue.

So this looks like a Windows Desktop regression around thread/composer state rather than a general network or account issue.

I am seeing a closely related issue on the same Codex App version (26.901.51231) on Windows x64, with an additional Codex Remote scenario.

Reproduction in my case:

Start a fresh Codex conversation on Windows and send a message normally.
Open the same conversation through Codex Remote on an Android tablet (Samsung SM-X200, Android 14).
Send a message from the tablet.
The Windows app receives the remote message and displays the completed response correctly.
After the response completes, the Windows app remains stuck in the running state with the blue Stop/spinner button.
The Stop button does nothing and I cannot send the next message from Windows.
Closing the Android app does not clear the stuck state.

I reproduced this in completely new chats, after restarting the ChatGPT/Codex app, and after revoking and re-pairing the tablet.

For comparison, I also tested Codex Remote with an Android 16 phone. After re-pairing the phone, the phone-to-Windows handoff worked correctly, while the tablet scenario continued to reproduce the problem.

I recorded a performance trace while the Windows app was stuck, including an attempt to press Stop, and uploaded it through the Codex App. I also submitted diagnostic feedback.

Feedback ID: 01a0835d-1f46-79b1-bb89-2b224c8dca40

Additional Windows reproduction: existing-thread send waits over 12 minutes before thread/resume

Adding measured evidence from another affected installation. This appears related to this issue, although the exact upstream cause has not been established. In this capture the affected thread remains notLoaded, and no new thread/resume was observed during the capture.

Environment and impact

Windows 11 Pro x64, OS build 10.0.26200.9445.
Installed MSIX package version: OpenAI.Codex 26.901.6511.0.
Desktop client version recorded in app-server logs: 26.901.51231. These are separate version fields; neither was copied from the About dialog.
Observed on 2026-09-09. The main application and app-server processes had been running for roughly 16 hours without restarting.
One existing thread shows a central loading indicator and a spinning Send button; the draft remains in the composer. A newly created diagnostic thread in the same application continues responding and running tools.
The user reports recurrence after extended use and inconsistent temporary benefit from Repair, Reset, reinstall, or renderer-cache cleanup. Those operations were not repeated during this capture.

Controlled capture (all times UTC)

Read the affected thread through the app's read-only task tool: response in 49 ms, runtime status notLoaded, latest persisted turn completed.
At 19:21:42, attempt exactly one diagnostic follow-up through the app's built-in task messaging tool, requesting only a fixed acknowledgement and explicitly forbidding tools or project work.
Desktop logs show successful responses around that attempt:

Method Duration

thread/read for the affected thread 2 ms

account/read 8 ms

getAuthStatus 14 ms

configRequirements/read 3 ms

config/read 10 ms
No corresponding stream-owner transition, thread/resume, or new turn start for that thread is observed. Non-thread-specific account/config calls cannot all be conclusively assigned to this attempt without additional correlation.
At 19:23 UTC and 19:34:15 UTC, read-only task status still reports notLoaded and the same previously completed turn. The user confirms that the UI spinner persists.
After approximately 753 seconds, the send call still has not settled. Only the local diagnostic orchestration wait is terminated. Application-side cancellation is unconfirmed; the message was not retried, and delivery is not claimed.

This is a captured recurrence, not a deterministic minimal reproduction of the initiating event.

Evidence against a pending core turn or general resource outage

The persistent app-server queue is empty.
This thread's durable rollout has 762 valid JSON records, continuous ordinals 0–761, and a fully caught-up projection at 18,414,946 bytes. There is no duplicate ordinal in this affected thread.
A different existing thread successfully completes thread/resume in 201 ms in the same application session.
Roughly 44–46 GiB RAM and 823 GiB disk space are free. A 25-sample resource series does not show global resource exhaustion; it is too short to exclude a longer-term leak.
MCP OAuth warnings also occur on working threads, so those warnings alone do not explain this per-thread pre-resume stall.

Code-level hypothesis, not a proven runtime stack

Read-only inspection of the installed renderer shows that maybeResumeConversation stores a per-conversation promise in inFlightConversationResumes. Later attempts reuse it; normal cleanup occurs in finally, with no overall resume deadline. Some local host-fetch prerequisites in resume preparation have neither a timeout nor a supplied abort signal. A request that never settles can therefore retain the resume slot indefinitely while other conversations work.

The exact unresolved prerequisite is not identified. Dynamic-tool declaration collection has a 10-second fallback, and the inspected config-requirements call has a 30-second timeout; neither should automatically be blamed for the multi-minute wait. A successful underlying RPC also does not prove an enclosing host-fetch reply reached the renderer.

Expected behavior / investigation request

Please correlate each pre-resume stage with its host-fetch request and response; identify the unreturned prerequisite. Resume should have bounded cancellation and safe cleanup, restore a retryable state on failure, and show an actionable error. Late replies must not revive a superseded attempt. Restart/cache cleanup should not be required to release one conversation's pending send.

No application files, settings, caches, SQLite rows, or conversation records were modified during diagnosis. No transcript content, screenshots, thread/request IDs, credentials, local paths, or raw logs are included in this public comment. Focused private identifiers can be supplied through a secure support channel if required.

Additional Windows reproduction on 10 September 2026, with a controlled successful send through the desktop task-messaging interface.

Environment

Installed Microsoft Store/MSIX package: OpenAI.Codex 26.903.9818.0 (read from Get-AppxPackage, not the About dialog).
Windows NT 10.0.26200.0, x64.
ChatGPT Plus; the account rate-limit tool reported 1% used in the 5-hour window and 46% used in the weekly window, with no rate-limit-reached flag.
The same symptoms were reported on package 26.903.8094.0 the previous day. Application logs confirm a restart on the newer package.

Symptoms
The user reports that multiple existing local conversations remain readable but their Send button stays gray or unresponsive with text entered. New conversations accept prompts. Esc and changing the draft did not help in the earlier test.

Measured evidence (UTC, 2026-09-10)

Two affected conversations successfully complete thread/resume in 142 ms and 132 ms at 11:12:03 and 11:12:26, respectively.
For the second conversation, maybe_resume_success at 11:12:26.343 records assignedStreamRole=owner, latestTurnStatus=completed, and markedStreaming=true.
The first affected conversation similarly reports latestTurnStatus=interrupted with markedStreaming=true. These log fields alone do not prove the root cause or establish how long the flag remains set.
At 11:15:04, one minimal diagnostic follow-up was sent to the second affected conversation using the app's built-in task-messaging tool, requesting only a fixed acknowledgement and no tools or project work.
The desktop log records a successful turn/start response in 47 ms. The turn completes after 16.4 seconds.
The original conversation's durable rollout contains the requested acknowledgement as an assistant final response and a matching task_complete event. The same account, existing conversation, and history can therefore still execute a follow-up via this interface.
An additional diagnostic discrepancy: read_thread returns this latest turn as completed but with items=[], while the durable rollout contains the response.

Other logs include remote-control WebSocket HTTP 403 failures and unknown-conversation event warnings. Their causal relationship to the disabled composer is unproven; they also coexist with a successfully working new conversation.

Current conclusion and request
This narrows the failure toward desktop composer/readiness or thread-state synchronization rather than quota exhaustion. The successful programmatic send is a workaround test, not evidence that the user's Send button is repaired.

Please investigate the completed/interrupted-versus-streaming state on restore, expose the composer blocking reason, and provide a supported recovery that preserves history and drafts. No app binaries, caches, settings, or databases were modified. This public report excludes screenshots, account identifiers, conversation identifiers, IP addresses, local paths, credentials, and private conversation content.

I can reproduce this issue consistently on the current Windows desktop app.

Environment:

ChatGPT/Codex desktop app: 26.908.4834.0
Codex runtime: 0.154.0-alpha.6.2
Windows 11 Pro x64, build 10.0.26200
ChatGPT Plus

Reproduction:

Start a new Codex chat.
Send "Antworte nur mit Test 1" -> response completes normally.
Send "Antworte nur mit Test 2" in the same chat.
The second message never leaves the composer and the UI remains in the running state indefinitely.
The Stop button also becomes unresponsive. Switching to another chat stops the stuck state.

Important isolation:

Codex CLI on the same PC/account works correctly for multiple consecutive turns.
Browser ChatGPT works normally.
Reproduces with multiple models.
Fresh .codex state did not fix it.
Windows App Reset + reinstall did not fix it.
Codex Workspace dependency reinstall/diagnostics did not fix it.
Elevated Windows sandbox setup completed successfully, but did not fix it.
Running the desktop app as Administrator did not fix it.
Both Steer and Queue follow-up modes were tested.
Codex Doctor reports healthy state databases, reachable provider endpoints and a successful Responses WebSocket handshake (HTTP 101).

I submitted in-app feedback with diagnostic logs from the affected Codex conversation at OpenAI Support's request.

Feedback ID:
01a09ad5-d8bb-7cf3-b1d6-3b3e36c859d1

OpenAI Support confirmed that this Feedback ID can be used to associate the affected Codex session with the captured desktop logs.

Additional visual evidence from the same account and same test:

Windows desktop app: first Work turn succeeds, second turn remains stuck indefinitely.
Chrome/Web: the same Work test completes successfully through three consecutive turns.

This A/B test was repeated after a full Windows app reset and a clean uninstall/reinstall.

I can reproduce this reliably on the current Windows desktop app as well.

Environment

ChatGPT Desktop for Windows
MSIX package: OpenAI.Codex
Package version: 26.908.4834.0
Windows x64

Reproduction

Open the Windows desktop app.
Create a brand-new Work task/conversation.
Send Teste 1 (or any first message).
The first response completes normally.
Send Teste 2 in the same task.
The app remains stuck indefinitely in the processing/spinner state and never returns the second response.

This is reproducible in completely new Work tasks, not only existing threads.

Browser comparison

I ran the same test using the same account in Chrome/Web: Teste 1, Teste 2, Teste 3 all complete normally. So the failure appears specific to the Windows desktop client rather than the account or Work backend in general.

Troubleshooting already attempted

Windows Repair for the app
Windows Reset/Restore (cleared local app data)
Sign-in again
Full uninstall with:
Get-AppxPackage OpenAI.Codex | Remove-AppxPackage
Windows reboot
Clean reinstall of the official desktop app
Re-tested with a brand-new Work task after reinstall

The behavior is unchanged: first turn succeeds, second turn hangs indefinitely.

This is especially notable because it still reproduces on 26.908.4834.0, which is newer than the versions reported earlier in this issue. I can provide screenshots or additional Windows diagnostics if useful.

Adding a sanitized log capture from the same Windows 26.908.4834.0 reproduction.

The sequence is notable because the desktop receives lifecycle events for a conversation it does not recognize:

2026-09-14T17:01:24.465Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=<redacted>
2026-09-14T17:01:24.744Z info  [AppServerConnection] ... method=turn/start ...
2026-09-14T17:01:28.806Z error [electron-message-handler] Received turn/completed for unknown conversation conversationId=<redacted>

After that completed turn, the user sent the second follow-up message in the same brand-new Work task. In this capture there is no subsequent turn/start before the app is closed several minutes later. This matches the UI symptom: the second message remains stuck indefinitely in the spinner/processing state.

The same log also shows the local app-server connection itself remains connected, and there is no account/auth failure around the affected turn.

This appears consistent with the earlier reports in this issue where the desktop UI/conversation routing becomes out of sync with the completed backend turn.

I have not posted raw logs because they contain local paths and identifiers. I can provide additional sanitized excerpts if useful.

I can confirm the same issue is still reproducible on a newer app version and on Windows 10.

ChatGPT/Codex app version: 26.908.70816
Windows: Microsoft Windows NT 10.0.19045.0 x64
Subscription: ChatGPT Plus

In Work mode, the first prompt completes normally. After that, I can type and edit a second prompt, but pressing Enter does not send it. The prompt remains in the composer and the conversation is effectively stuck. Starting a new Work conversation allows one first prompt, but the same problem occurs again on the follow-up.

I reproduced it after:

Completely reinstalling the latest Microsoft Store version.
Testing with a completely fresh %USERPROFILE%\.codex folder.
Testing both sandbox = "elevated" and sandbox = "unelevated".
Restarting the app and Windows processes completely.

Normal Chat mode works correctly with multiple consecutive messages. The problem appears limited to Work mode.

During elevated sandbox setup, the log also reported:

helper_sandbox_lock_failed: SetNamedSecurityInfoW sandbox dir failed: 5

However, the follow-up freeze still occurred with the unelevated sandbox.

Feedback ID with ChatGPT diagnostic logs:

no-active-thread-01a0a60c-35f8-70e1-aafd-6524040c6f6b

I finally fixed this issue on my machine.

My symptom was exactly the same: the first message in a new Codex conversation worked, but the second message would stay stuck indefinitely.

In my case, the root cause turned out to be stale authentication. My Google account password had been changed, but Codex Desktop still appeared to be logged in and did not ask me to authenticate again.

After changing/resetting the password and then fully signing out of Codex and signing back in with ChatGPT/Google, multi-turn conversations immediately started working again.

So if you have this issue, I recommend trying a full logout and re-login, especially if your Google/OpenAI account credentials were changed recently. The app may appear authenticated even though its cached authentication state is no longer valid.

@shanshan1231

I was having the same issue, and exactly @shanshan1231 explained, a full log out of the app and website, and log in again solved it.

Additional isolation — reproduced immediately after a full usage-limit reset

I performed another controlled test today (Sep 22) that rules out account usage/quota exhaustion as the cause.

Before the test, my shared weekly Work/Codex usage limit had been exhausted. I used one of the available Full resets under Settings → Usage & billing → Usage limit resets.

After the reset, the Usage page explicitly showed:

Weekly limit: 100% left
a new weekly reset period had started

I then opened a fresh Work task in the Windows desktop app and reproduced the issue again:

First prompt → completes normally.
Second prompt in the same Work task → hangs indefinitely and does not proceed normally.

So the issue is still reproducible with a freshly restored 100% weekly usage allowance.

This adds usage-limit/quota state to the conditions already ruled out in my previous testing:

Windows Repair / Reset
full uninstall and clean reinstall
sign out / sign in
Tailscale completely disconnected
no WinHTTP proxy
no proxy environment variables
fresh Work task
regular ChatGPT conversations work normally
the same account/network works for multi-turn Work in the browser

This also remains consistent with the desktop log evidence I previously posted, where the failed follow-up does not result in a subsequent turn/start.

Several related reports now appear to point to the Windows Desktop local initialization/renderer path (loading-local-config / pending codex-home state), rather than the model/backend or the conversation itself.

The issue remains fully reproducible on my system after the usage reset. Could this please be escalated to the Windows Desktop / Work engineering team?

Update: the logout/sign-in workaround only fixed the issue temporarily.

After fully signing out and signing back in with ChatGPT/Google, Work mode initially allowed three consecutive messages in the same conversation.

Later, after closing the desktop app, it would no longer launch and no ChatGPT process appeared in Task Manager. I used Windows Settings → Apps → ChatGPT → Advanced options → Repair, which allowed the app to open again.

However, the original issue then returned: the first message in a Work conversation completes, but the second message in the same thread remains stuck and is never sent.

App version: 26.908.70816
Windows: Microsoft Windows NT 10.0.19045.0 x64
New feedback ID with diagnostic logs: 01a0d3eb-30d5-7560-97df-3eb1955771b5
Previous feedback ID: no-active-thread-01a0a60c-35f8-70e1-aafd-6524040c6f6b

The new report was submitted directly from a Work conversation affected by the problem, with ChatGPT diagnostic logs included.

Navigation Menu

Repository navigation

Windows desktop app: second/follow-up message hangs indefinitely in Work and Codex after Sep 5 update #43366

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Symptom

Reproduction

Local diagnostics

Expected behavior

Additional Windows reproduction: existing-thread send waits over 12 minutes before thread/resume

Environment and impact

Controlled capture (all times UTC)

Evidence against a pending core turn or general resource outage

Code-level hypothesis, not a proven runtime stack

Expected behavior / investigation request

Environment

Reproduction

Browser comparison

Troubleshooting already attempted

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Method	Duration
`thread/read` for the affected thread	2 ms
`account/read`	8 ms
`getAuthStatus`	14 ms
`configRequirements/read`	3 ms
`config/read`	10 ms

Windows desktop app: second/follow-up message hangs indefinitely in Work and Codex after Sep 5 update #43366

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 7, 2026

Jiaming-git commented on Sep 7, 2026

Environment

Symptom

Reproduction

Local diagnostics

Expected behavior

sanzhang2 commented on Sep 9, 2026

henrikesalgado05-source commented on Sep 9, 2026

ibrahimo-ops commented on Sep 9, 2026

Additional Windows reproduction: existing-thread send waits over 12 minutes before thread/resume

Environment and impact

Controlled capture (all times UTC)

Evidence against a pending core turn or general resource outage

Code-level hypothesis, not a proven runtime stack

Expected behavior / investigation request

zhuhongjia999-bit commented on Sep 10, 2026

noppiesrep-beep commented on Sep 13, 2026

Juka-Bala commented on Sep 14, 2026

Environment

Reproduction

Browser comparison

Troubleshooting already attempted

Juka-Bala commented on Sep 14, 2026

ToniJazz64 commented on Sep 15, 2026

shanshan1231 commented on Sep 16, 2026

sebastianleytonr commented on Sep 16, 2026

Juka-Bala commented on Sep 22, 2026

ToniJazz64 commented on Sep 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions