Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn

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

Windows Desktop 26.903.61454

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

After updating ChatGPT Desktop for Windows to version 26.903.61454 on September 9, 2026, I can no longer send follow-up messages in a conversation.

The issue affects both existing and newly created conversations:

In existing conversations, I can type into the composer, but the Send button remains disabled/gray. Clicking it changes the button to a spinner, but the message is never added to the conversation.
In a newly created conversation, the first message sends normally and receives a response, but any subsequent message in the same conversation cannot be sent.
The problem started immediately after updating to version 26.903.61454.

The web version of ChatGPT is not showing the same composer behavior, so this appears to be specific to the Windows Desktop client.

What steps can reproduce the bug?

Launch ChatGPT Desktop on Windows.
Create a new conversation.
Send the first message.
Wait until the assistant finishes responding.
Type a second message.
Click the Send button.

Alternatively:

Open an existing conversation whose previous response has already completed.
Type a new message.
Click Send.

What is the expected behavior?

Once the previous turn has completed, the composer should return to an idle/enabled state and allow another message to be submitted normally.

Additional information

Relevant Log Evidence

There appear to be two related state inconsistencies.

Completed turns are restored as still streaming

When existing conversations are resumed, the Desktop client logs states such as:

latestTurnStatus=completed
markedStreaming=true

This happens across multiple conversations.

This suggests that the app-server considers the latest turn completed, while the Desktop renderer still restores the conversation as streaming/busy.

That would explain why the composer remains disabled after the response has already completed.

No second turn/start is generated

For a newly created conversation, the first turn is submitted normally:

method=thread/start
...
Conversation created conversationId=01a08531-3ff4-78f1-b9f3-a652dd06a48c
...
method=turn/start
errorCode=null

However, after reproducing the issue by attempting to send the second message, there is no second method=turn/start entry anywhere later in the log.

This suggests that the second Send action is getting stuck in the Desktop UI / renderer state before the request reaches the local app-server.

Unknown conversation lifecycle events

The same session also contains:

Received turn/started for unknown conversation
conversationId=01a08531-419b-7e92-9ba0-e40c7138e4cf

and later:

Received turn/completed for unknown conversation
conversationId=01a08531-419b-7e92-9ba0-e40c7138e4cf

The visible conversation created at the same time was:

01a08531-3ff4-78f1-b9f3-a652dd06a48c

I am not certain whether the 419b... conversation is an auxiliary/ephemeral thread, but it may be relevant to the renderer/conversation routing issue.

Additional Notes
The local app-server initializes successfully.
Authentication succeeds.
The first turn/start succeeds.
This does not appear to be a general connectivity failure.
The failure is highly deterministic: first message works, follow-up messages do not.
The regression started immediately after updating to 26.903.61454.

I can provide the full Desktop logs from the reproduction session if needed.

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

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

Powered by Codex Action

Update: signing out of the ChatGPT Windows Desktop app and signing back in resolved the issue for me.

After re-authenticating, I tested both existing and newly created conversations, and follow-up messages are sending normally again across multiple turns.

So in my case, this appears to have been a local session/conversation-state issue triggered after the 26.903.61454 update, and re-login acted as an effective workaround.

Confirmed on a newer Windows Desktop build, 26.903.8094.0, with bundled codex-cli 0.153.4.

Additional isolation evidence from #44295:

The first turn is completed in both the session transcript and thread_history_1.sqlite.
On the second submit, Desktop emits thread-queued-followups-changed, but no second turn/start or turn/steer appears.
queue_1.sqlite has no queued item for the affected thread, and the persisted queued-follow-ups object is empty.
The issue reproduces with VS Code fully closed.
It persists after changing Queue to Steer, rebuilding Chromium Cache/Code Cache, and temporarily disabling the bundled Computer Use plugins.
CLI and the VS Code extension handle multiple turns normally with the same account/configuration.

This supports the report's conclusion that Desktop retains or derives an incorrect busy/streaming state after the completed first turn, before the second request reaches app-server. I am closing #44295 as a duplicate of this issue.

Additional verification from the same affected Windows installation (2026-09-10):

Microsoft Store package: OpenAI.Codex_26.903.8094.0_x64
Internal desktop app version: 26.903.61454
The Store currently reports that no newer package update is available.
The bug still reproduces after a cold launch with a newly created explicit --user-data-dir profile.
Acceptance test: type and send the first message in a new visible page, wait for completion, then type and send a second message in that same page. The first send succeeds; the second is not submitted.
At the failure point the log reports latestTurnStatus=completed together with markedStreaming=true.
No second turn/start is emitted after the second Send action.
The clean-profile reproduction did not produce a new EXDEV error, so changing the Chromium profile path alone does not resolve this regression.
Side-by-side package OpenAI.CodexBeta_26.727.4816.0_x64 passes the exact same-page test on the same machine and account: two ordinary typed messages can be sent consecutively without navigating or creating another conversation.

This comparison further isolates the regression to desktop client state handling in the current stable build rather than authentication, service connectivity, or the conversation data itself. Please ensure that a completed latest turn cannot leave the composer in a streaming/busy state, and add a regression test requiring at least two typed sends in the same visible conversation.

I can provide additional sanitized logs if a maintainer needs them; no private prompts, account identifiers, session IDs, or local paths are included here.

Windows 11 x64, ChatGPT Plus, Codex Desktop 26.903.61454.
The issue remains reproducible after reinstalling the official Windows package.
The custom follow-up queue setting was also removed.
The first turn completes normally, but the second message remains disabled or spins indefinitely and never appears.
The web client does not show the same behavior.
Local logs show successful authentication, app-server initialization, and first-turn submission, with thread/status/changed targeted_connections=0 during resume.
-The problem was solved after re-login, but it still occurred after restarting the Codex.
This appears to be a renderer/conversation lifecycle regression rather than a quota, authentication, local injector, or installation issue. Sanitized logs are available if needed.

Adding a cross-surface reproduction on Windows Desktop 26.903.61454 (released Sep 8, 2026).

I can reproduce this on the same cloud conversation across Desktop and Web:

A turn remains active and progresses normally on chatgpt.com.
Opening the same conversation in Desktop while that Web turn is still running can show “Analysis paused”, even though the Web turn is still progressing.
In another occurrence on the same Desktop build, the conversation rendered normally but the composer disappeared entirely — there was no input box at all. Opening that exact same conversation on Web at the same time showed the normal composer and allowed me to continue the conversation.
I have also seen ChatGPT stream recovery polling timed out in Desktop when opening conversations that had previously been used on Web.
Once the Web-side turn reaches completion, returning to Desktop later can show the completed result normally again.

This seems broader than only a disabled Send button after a completed first turn: Desktop can temporarily hold an inconsistent active-turn/conversation state while Web continues to show a usable current state for the same cloud conversation.

I am not asserting a specific root cause, endpoint, or transport failure.

Windows desktop follow-up submission hangs before turn/start

Observed September 10, 2026. App version 26.903.71938; Windows package 26.903.9818.0; bundled Codex backend 0.153.4.

Reproduction performed directly in the desktop UI:

Create a Work chat without a project.
Send: Reply only: FIRST. Do not use tools.
The assistant returns FIRST and completes.
Send: Reply only: SECOND. Do not use tools.
SECOND remains in the composer with a spinner; no new user bubble or backend turn is created.

The same failure occurs inside a project. Tested GPT-6 Astra Medium. Changing Queue to Steer, ChatGPT to Codex interface, opening the conversation in a separate window, and enabling the plain-text composer all reproduce the same failure. Original Queue and rich-text preferences were restored. Restarting, disabling a custom model catalog override, and clearing generated Cache / Code Cache / Session Storage did not fix it. The app reports it is up to date.

Local inspection shows the first turn completes and conversation read/resume works. The follow-up does not produce turn/start. This supports a desktop pre-submission hang; the exact unresolved operation is not identified. CLI/desktop sync conflict is not established. The markedStreaming=true resume log field is hardcoded in this build and should not be treated as proof that a completed turn remains active. Unknown-conversation events can belong to auxiliary title-generation threads.

Related open reports:
#44102
#40968

Requested engineering action: identify the pending frontend operation between the composer submission handler and turn/start; provide a supported fix or signed known-working Windows build. No private chat content, account identifiers, or raw logs are included in this report.

Additional reproduction and state-isolation evidence from Windows Desktop 26.903.71938.

Symptoms:

New project/conversation: first prompt submits and completes normally.
Any follow-up prompt in the same conversation becomes unsendable: as soon as text is entered, the Send button is disabled/gray.
Existing conversations show the same follow-up failure.
Usage/quota is not exhausted.
Removing the entire ~/.codex directory restores behavior only temporarily; the issue returns after some hours.

Key isolation result:

I did not need to remove the whole ~/.codex directory.
Renaming only ~/.codex/.codex-global-state.json and letting Desktop regenerate it immediately restored multi-turn submission.
The old file is valid JSON (not truncated/corrupt), about 391 KB, so this appears to be a persisted-state problem rather than file corruption.

A/B comparison of the persisted permission / agent-mode state:

Broken state:

permission-selection-by-host-id:local
  {"kind":"agent-mode","agentMode":"guardian-approvals"}

agent-mode-by-host-id
  {"local":"guardian-approvals"}

preferred-non-full-access-agent-mode-by-host-id
  {"local":"guardian-approvals"}

composer-permission-mode-visibility
  true

config-derived-agent-mode-by-host-id
  absent

Healthy state regenerated by the app:

permission-selection-by-host-id:local
  absent

agent-mode-by-host-id
  {"local":"granular"}

preferred-non-full-access-agent-mode-by-host-id
  absent

config-derived-agent-mode-by-host-id
  {"local":"granular"}

composer-permission-mode-visibility
  absent

The broken file also contained stale top-level state including thread-project-assignments, queued-follow-ups, and thread-writable-roots, while the regenerated healthy file contained thread-workspace-root-hints / projectless-thread-ids. queued-follow-ups itself was empty, so the failure does not look like an actually queued second turn.

This suggests a persisted permission/agent-mode migration or desynchronization problem: legacy guardian-approvals host state can survive while the current client derives granular mode from configuration. The first turn still completes, but the composer becomes blocked when preparing the follow-up turn.

This seems related to the stale guardian-approvals state discussed in #40698, and may be a useful trigger/root-cause clue for this follow-up submission regression.

Local config note: the only manual config change was:

approval_policy = "on-request"

Removing/rebuilding the global state fixes the UI without changing that config, so the config line itself does not appear to be the direct cause.

Workaround confirmed on this machine: fully exit Desktop, rename .codex-global-state.json, restart Desktop, then multiple turns work again until the state regresses.

I can reproduce the same issue on Windows 10 with Codex package version 26.903.9818.0.

The behavior is:

The first message in a new conversation works normally.
The second message gets stuck on the spinner.
The second turn does not start.
Restarting Codex, killing the app processes, re-selecting the model, and re-selecting the permission mode did not fix it.

I found a workaround:

Sign out of Codex.
Sign back in.
Multi-turn conversations work normally again.

This suggests the issue may be related to persisted authentication/account session state rather than only the conversation or workspace state.

Before re-login, I also observed:
latestTurnStatus=completed
markedStreaming=true

During the failed second submission, no new turn/start was observed.

Feedback ID:
01a090a8-0b7b-70e0-823b-a070e3668142

I have not yet confirmed whether the issue will return after the new login session has been active for some time.

Workaround found on Windows without restarting Codex

I can reproduce this issue on:

OpenAI.Codex 26.903.9818.0 — Windows

My logs show the same inconsistent state:

latestTurnStatus=completed markedStreaming=true

I found a workaround that restores the Send button without closing Codex, resetting .codex, or restarting the whole application.

Steps:

Open Codex's built-in Task Manager.
Go to All Tasks.
Find the stuck “Prerender” / “Renderizador anticipado” processes.
End those tasks.
Codex automatically refreshes/recreates the renderer.
The previously disabled Send button becomes usable again.

I had multiple stuck Prerender processes. After terminating them, the app refreshed and messaging immediately worked again.

This seems consistent with the renderer keeping a stale streaming state even though the turn is already marked completed.

Importantly, I did not need to kill the main renderer, app-server, Network Service, Storage Service, restart Codex, install Git, or reset local Codex data.

This may be useful as a temporary workaround and could also help identify which renderer state is causing the regression.

I can confirm that this issue is still reproducible on Codex Desktop 26.908.40834 on Windows.

In my case:

the first message in a new session sends successfully;
Codex responds normally and the first turn completes;
the second message remains in the composer with the Send button spinning indefinitely;
the second message is never recorded in the session transcript as a new UserMessage;
there is no new turn/task start after the first task_complete;
I do not see corresponding websocket, timeout, 401, or 403 errors in the affected session log.

I reproduced this:

after fully restarting Codex Desktop;
after signing out and back in;
in brand-new sessions;
in a completely new project;
across multiple Codex models;
on a different network/mobile hotspot;
with VPN/proxy disabled.

While the second message is stuck, the integrated PowerShell terminal remains responsive. Get-Date and Get-Location execute normally, so the app itself is not completely frozen.

Codex is also not waiting for an approval. The affected session uses approval_policy: on-request.

Feedback ID from the in-app / feedback flow:
no-active-thread-01a09a9a-ef08-7ae1-9b37-7c9ff95d7122

I have also reported this through OpenAI Support with the relevant session logs.

This looks like the desktop client/UI getting stuck before the second turn is actually submitted.

Temporary workaround that may help others experiencing this issue:

I found that while follow-up messages are stuck and cannot be sent from Codex Desktop on Windows, I can still continue the same Codex conversation from the ChatGPT mobile app.

Messages sent from my phone go through normally and Codex responds, even while sending from the Windows Codex Desktop app is not working.

So, if anyone urgently needs to continue working while this bug is being fixed, try opening the affected Codex conversation in the ChatGPT mobile app and send your prompts from there.

This is obviously not a replacement for the Desktop app, but it works as a temporary workaround for me.

Temporary workaround that may help others experiencing this issue:

I found that while follow-up messages are stuck and cannot be sent from Codex Desktop on Windows, I can still continue the same Codex conversation from the ChatGPT mobile app.

Messages sent from my phone go through normally and Codex responds, even while sending from the Windows Codex Desktop app is not working.

So, if anyone urgently needs to continue working while this bug is being fixed, try opening the affected Codex conversation in the ChatGPT mobile app and send your prompts from there.

This is obviously not a replacement for the Desktop app, but it works as a temporary workaround for me.

codex CLI still works fine,
so you can use it.
if you want to read in the codex desktop, open cli first and enter your conversation there, then open codex on desktop.
that way you can send your messages using powershell, and then read them on codex. you do however need to refresh desktop conversation to see what it wrote.

Additional reproduction on Windows Desktop package 26.908.4834.0 (Windows 11 Pro 25H2, build 26200.9445, x64):

New Work chats can send normally, but at least one existing legacy Work chat leaves the blue Send control spinning indefinitely.
Voice can continue the affected chat.
Reinstall, Windows restart, Task Manager termination, Repair, and Reset did not resolve it.
Opening the affected chat logs Conversation state not found, followed by a successful thread/resume and maybe_resume_success.
An internal app-server continuation of that same thread succeeds in about 7 seconds, confirming that authentication, connectivity, thread data, and model execution are available.
Immediately afterward, a manual Send-button attempt in the visible desktop chat creates no user item, does not modify the rollout, and emits no turn/start.

Controlled sign-out/sign-in result on 2026-09-14 (KST):

12:36:24 — account/logout completed with errorCode=null.
12:36:42 — account lookup completed with authenticatedAccountPresent=true.
12:37:05 — a follow-up in a recently created existing chat successfully emitted turn/start.
12:39:19 — the affected legacy chat reopened and completed thread/resume; its latest turn was reported as completed.
A manual typed Send attempt in that visible legacy chat then remained stuck. No turn/start was emitted before the view became inactive at 12:44:46, and the session transcript remained unchanged at its pre-test 12:11:49 timestamp.

The user also reports that signing out and back in restores sending only temporarily before the failure returns. Therefore re-authentication is a transient workaround on this installation, not a durable fix.

This is consistent with the pre-submission renderer/composer failure already documented here. One additional migration clue is that 97 non-archived user threads created by older desktop versions have no originator value in the local thread index, while newly created working threads use originator=codex_work_desktop. This correlation does not by itself prove causation, but may help isolate legacy conversation-state hydration.

No private prompts, account identifiers, thread IDs, local paths, or raw logs are included. Sanitized timestamped excerpts are available if a maintainer requests them.

Windows Codex Desktop：第二条消息无限转圈、界面语言异常及完整排查记录

日期：2026 年 9 月 15 日
相关问题：#44102
补充参考：#45069

这份记录整理了我本人实际进行的操作、我观察到的结果，以及 AI 在本机检查日志和代码后得到的证据。以下明确区分已确认事实和推测，不把临时恢复当成永久修复。

一、我遇到的问题

我使用 Windows Codex Desktop 时，新聊天第一条消息通常可以发送，模型也能正常回复并结束。但在同一个聊天发送第二条消息时，发送按钮会变成转圈，文字停留在输入框，不进入聊天历史，长时间等待也没有结果。

另一个伴随现象是界面语言：正常运行时主体界面常为中文；出现异常的运行实例有时主体界面变成英文，而部分原生菜单仍能显示中文。我没有证据证明语言异常直接导致发送失败，但两者同时出现和恢复的现象值得记录。

我要求整个排查过程保留当前登录，不退出账号，不修改或删除 auth.json，不清空 .codex，不删除聊天历史，任何本地状态修改前必须先备份，并优先进行只读分析。

二、在这次详细排查前，我已经做过什么

1. 检查全局状态及其备份

此前已检查 .codex-global-state.json 和同名 .bak：在当时的检查时间，两者均为 1,103,295 bytes，修改时间一致，SHA256 完全相同。这说明该 .bak 不是可以直接恢复的历史健康状态。

当时的字符串检查结果是：

guardian-approvals：不存在。
granular：存在。
queued-follow-ups：存在。
permission-selection-by-host-id：存在。

因此，我没有直接照搬其他用户“删除或重建 global state”的方法。字符串出现与否也不是完整的运行时状态验证。

2. 在 Codex 内置任务管理器结束备用渲染程序

我打开了 Codex 内置任务管理器，看到浏览器、渲染程序、GPU、Network Service、Storage Service 和备用渲染程序，没有明确名为 Prerender 的条目。

我尝试结束“备用渲染程序”：原 PID 为 13136，随后应用创建了新的 PID 36964。Browser CPU 一度下降，但第二条消息发送失败没有恢复。

这个实验只说明重建该备用渲染程序没有解决我的问题，不能证明主窗口 renderer 没有问题，也不能把 Spare Renderer 等同于其他用户报告中的 Prerender。

三、AI 在本机检查到了什么

AI 主要读取了安装包、Desktop 日志、配置及聊天记录，没有修改认证信息或清理历史。

本机安装包版本为 OpenAI.Codex 26.908.9136.0。
较早的运行实例使用名为 codex-desktop-repaired 的自定义数据目录；后来的运行实例使用默认启动方式，没有该覆盖参数。这个变化不是本次 AI 排查主动设置的。
当前检查到的 config.toml 没有显式 desktop.localeOverride。进程中出现的 --lang=zh-CN，不能直接当成前端已经应用中文翻译的证据。
安装包存在普通 composer 的 loading-local-config 等待分支：提交动作可能先被暂存，界面显示 spinner，待配置或工作目录状态就绪后才真正提交。
安装包也存在 codex-home 无数据时，工作目录状态保持 loading 的路径。这与 Codex desktop (Windows): follow-up messages in existing threads never send #45069 报告者描述的链路相似，但没有在我的失败实例中抓到对应 Promise 或 query 的实时内存值。
前端翻译还取决于 enable_i18n 开关、locale 来源及异步翻译资源加载。原生菜单中文与主体界面英文并不必然矛盾。

以上提供了候选解释，但 AI 没有定位并修复我的具体根因。

四、我配合进行的第一次定时测试

15:56：在已有聊天点击第二次发送

我在标题以“可以。下面我给你整理……”开头的已有聊天中，通过 Windows 普通输入框尝试发送 SECOND-DIAG-0915，并报告点击时间约为 15:56，主体界面英文。

随后，我通过手机或其他入口，把测试文字、时间、聊天标题和界面语言发给 AI，并继续发送了“继续”。我明确确认，后面这些成功发送的消息不是通过同一个 Windows 普通输入框发送的。

后台核对结果：

该聊天在 15:50 已成功完成 thread/resume，上一轮为 completed，主窗口取得 owner。
聊天记录中没有 15:56 那条独立测试消息。
检查窗口内没有对应的新 turn/start 或 turn/steer 响应记录。
15:57 发给 AI 的“测试文字＋时间＋标题＋英文”说明进入了同一聊天，并启动了新一轮。
后来的“继续”也进入了聊天记录。

这形成了同一聊天的实际对照：Windows 普通输入框失败，手机或其他入口可以继续执行。

本次还发现的状态差异

恢复聊天时，一条日志中后端返回 never / dangerFullAccess，而前端推导为 on-request / workspaceWrite，并记录 hasLatestThreadSettings=false 等字段。

这说明两边记录的状态存在差异，但没有证明这个差异就是发送失败的原因，也没有证明这些派生值已经写回后端。

15:58 左右该实例结束，AI 因此没有取得那次失败时的前端内存快照。

五、我配合进行的第二次独立测试

AI 让我另开一个测试聊天，把实验与排查聊天分开。我按要求进行了以下操作：

在 Windows Codex 新建聊天。
发送“请只回复 OK”。
等待第一轮回复完成，聊天标题显示为“回复 OK”。
在该聊天输入第二条测试文字并点击发送。
发送按钮再次持续转圈。
保持电脑测试窗口打开，通过手机回到排查聊天报告结果，说明电脑主体界面是英文。

后台核对结果：

16:03:52.958：首轮开始。
16:03:57.440：首轮完成。
16:04:01.806：主窗口记录 resumed、owner。
16:04:07.333：该线程的 settings/update 成功返回，耗时约 1ms。
检查时没有第二条测试消息入库，也没有第二轮 task_started。

因此，模型能完成首轮，线程设置更新也可以成功；第二条消息仍未形成新的持久化回合。

AI 随后承认：保持窗口打开只是保留故障现场，当前实例没有开放调试接口，不能因此就直接读取卡住的 Promise。此前让我保持窗口以便“抓取阻塞状态”的说法不够准确。

六、我配合退出应用，尝试调试启动

在我表示准备好后，AI 生成并启动了一个隐藏的 PowerShell 后台助手。设计是：

等待我正常退出 Codex。
备份 config.toml、全局状态及其 .bak。
沿用当前默认数据目录，以仅本机可访问的调试端口重新启动 Codex。
不触碰 auth.json，不退出账号，不清理数据。

16:09:02，助手状态记录为“等待用户退出”。

我随后直接退出了 Codex，但应用没有按预期自动重新打开。

后台核对发现：

原 Codex 在 16:09:37 左右记录了窗口、IPC 关闭及主动停止 app-server。
助手状态文件只有“等待退出”一行。
没有备份完成、启动请求或调试就绪的记录。
没有生成预定的 state-backup 目录。
助手进程已经消失。

因此，自动启动方案没有完成，也不能声称该方案已完成备份。

AI 推测，隐藏 PowerShell 可能仍受 Codex 的进程组或作业生命周期管理，随 Codex 一起退出。由于没有取得进程退出码或相关审计记录，这仍是推断。AI 承认其后台助手设计没有保证独立存活，自动重开的承诺过于确定；这不是我的操作错误。

七、我手动重新打开后，界面和发送恢复

自动重开没有发生后，我手动打开了 Codex。

这一次我观察到：

主体界面恢复为中文。
可以继续发送消息。

后台日志提供了相应支持：

16:14:50.362：新的正常 prod 实例启动。
启动命令没有调试参数，也没有自定义 user-data-dir 覆盖。
16:17:10.679：当前主窗口向已有排查聊天提交 turn/start，111ms 返回，errorCode=null。
同一聊天记录在 16:17:10.678 出现 task_started。

这次恢复发生在我手动正常启动以后，不是后台助手自动启动的结果，也不是 AI 执行 query cancel/refetch、修改配置、清理缓存或重新登录的结果。

本次可以认定当前运行实例恢复了，不能认定永久修复。

八、哪些结论需要修正或保留

普通输入框与其他入口确有差异。 我的 Windows 第二次发送失败，而手机或其他入口能继续同一聊天。
不能单靠 Desktop 日志缺少 turn/start 判断任何入口都没执行。 AI 曾发现聊天记录已存在新一轮，但 Desktop 响应日志没有相应条目，因此必须结合具体测试文字和聊天记录核对。
query-cache-invalidate 警告不是故障的充分证据。 手动启动后的正常实例也出现了该警告，而且较早出现。因此仅凭这条警告或启动时序不能判定故障。
语言与发送同时恢复只是相关性。 没有证据证明切成中文就是修复发送的方法。
codex-home 悬挂仍是候选。 安装包存在相关链路，其他用户有运行时证据，但我的机器没有完成同样的实时验证。
本次退出不应写成自发崩溃。 是我主动退出，日志符合正常关闭流程；关闭时的 EPIPE、IPC reset 等不能直接当成根因。
本轮排查没有产出可靠修复。 得到了更完整的复现和日志，但没有定位我机器上具体卡住的 Promise，也没有建立可重复有效的恢复方法。

九、我最终的使用选择

这轮排查让我反复测试、提供时间和标题、在手机与电脑间切换、保持故障窗口、退出并重新打开应用。最终后台助手没有完成预期工作，恢复发生在我自己手动重新启动以后。现在我更愿意先使用能实际完成工作的入口，等待后续版本更新。

用AI修AI就是浪费时间的行为，更浪费算力。最好的方法就是用手机的远程操控来使用 CodeX。然后等下一次更新就完事了。

Update: I found the cause in my case

I wanted to share an update because this may help other users experiencing the same Codex Desktop freeze.

In my environment, the issue was related to an external MCP server used by Codex Desktop.

My setup is:

Spring Boot 4.1.1
Spring AI 2.0.1
MCP Server: STATELESS
Spring MVC
PostgreSQL
Codex Desktop on multiple Windows/macOS machines

The important detail is that I was already using STATELESS before the problem was fixed, and I am still using STATELESS now.

So, in my case, switching from STATELESS to STREAMABLE was not necessary.

Previous configuration

Initially, my MCP server was configured approximately like this:

spring:
  ai:
    mcp:
      server:
        protocol: STATELESS
        type: SYNC
        capabilities:
          resource: false
          tool: true
          prompt: false
          completion: false

At that time, Spring AI 2.0.1 was resolving MCP Java SDK 2.0.0.

Codex Desktop still performed requests/probes such as:

resources/list
resources/templates/list
notifications/initialized

The MCP server logs showed:

WARN DefaultMcpStatelessServerHandler
Missing handler for notification type: notifications/initialized

and:

ERROR WebMvcStatelessServerTransport
Failed to handle request:
Missing handler for request type: resources/templates/list

and:

ERROR WebMvcStatelessServerTransport
Failed to handle request:
Missing handler for request type: resources/list

This correlated with Codex Desktop conversations becoming stuck.

In some conversations, the first interaction would complete successfully, but later messages could remain indefinitely in a busy/spinning state.

MCP Java SDK bug

The main issue appears to have been the behavior of MCP Java SDK 2.0.0 in STATELESS mode when receiving a request for which no handler was registered.

Instead of cleanly returning the expected JSON-RPC error, such as:

-32601 Method not found

the missing handler could propagate as an HTTP transport failure / HTTP 500.

This is documented in the MCP Java SDK:

modelcontextprotocol/java-sdk#784
fixed by modelcontextprotocol/java-sdk#800
released in MCP Java SDK 2.0.1

There is also a Spring AI issue related to the SDK dependency version:

spring-projects/spring-ai#6998

What I changed

I kept:

Spring AI 2.0.1
protocol = STATELESS
type = SYNC

but upgraded/overrode the MCP Java SDK from:

MCP Java SDK 2.0.0

to:

MCP Java SDK 2.0.1

I also changed my MCP capabilities so that they are now all enabled:

spring:
  ai:
    mcp:
      server:
        protocol: STATELESS
        type: SYNC
        capabilities:
          resource: true
          tool: true
          prompt: true
          completion: true

So the current working configuration is:

Spring AI 2.0.1
MCP Java SDK 2.0.1
protocol = STATELESS
resource = true
prompt = true
completion = true
tool = true

Result

After these changes:

resources/list stopped producing the HTTP 500 error
resources/templates/list stopped producing the HTTP 500 error
the notifications/initialized missing-handler warning disappeared
Codex Desktop stopped freezing in my tests
conversations that were previously stuck started working again
I was able to continue sending follow-up messages normally
I did not need to migrate the server from STATELESS to STREAMABLE

One particularly interesting result was that some already-stuck conversations started working again after the MCP server was updated.

Maven note for Spring AI 2.0.1 users

In my dependency tree, Spring AI 2.0.1 was still resolving MCP Java SDK 2.0.0.

I explicitly aligned the MCP SDK to 2.0.1 using its BOM:

<properties>
    <spring-ai.version>2.0.1</spring-ai.version>
    <mcp-sdk.version>2.0.1</mcp-sdk.version>
</properties>

<dependencyManagement>
    <dependencies>

        <dependency>
            <groupId>io.modelcontextprotocol.sdk</groupId>
            <artifactId>mcp-bom</artifactId>
            <version>${mcp-sdk.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>${spring-ai.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

    </dependencies>
</dependencyManagement>

Then I verified the actual resolved versions with:

mvn dependency:tree -Dincludes=io.modelcontextprotocol.sdk

to make sure all MCP Java SDK modules were using 2.0.1.

Important clarification

I cannot say with certainty that enabling:

resource = true
prompt = true
completion = true

was independently responsible for fixing the problem.

Two things changed in my environment:

1. MCP Java SDK 2.0.0 -> 2.0.1
2. resource/prompt/completion false -> true

However, the HTTP 500 behavior I was seeing matches a known bug in MCP Java SDK 2.0.0, and that bug was explicitly fixed in 2.0.1.

The key point is that STATELESS itself was not the issue, because my server was STATELESS both before and after the fix.

My current working setup is still:

Codex Desktop
      |
      | HTTP
      v
Spring AI MCP Server
STATELESS
      |
      v
PostgreSQL

Possible Codex-side robustness issue

There may still be a Codex-side robustness issue worth investigating.

An external MCP server returning an unexpected HTTP 500 during an optional MCP probe should ideally surface an MCP error and allow the conversation to continue.

It probably should not leave the entire Codex conversation permanently stuck in a busy/streaming state.

So even though updating the MCP Java SDK fixed the problem for me, Codex may benefit from more defensive handling when an MCP server fails during capability discovery or initialization.

For anyone using Spring AI / Java MCP servers and seeing similar Codex freezes, I would recommend checking the MCP server logs for:

Missing handler for request type: resources/list
Missing handler for request type: resources/templates/list
Missing handler for notification type: notifications/initialized

and checking the actual resolved MCP Java SDK version.

In my case, the combination that is currently stable is:

Spring AI 2.0.1
MCP Java SDK 2.0.1
STATELESS
resource = true
prompt = true
completion = true
tool = true

and Codex Desktop has remained stable so far.

Additional observation: Codex should probably isolate MCP failures from the conversation lifecycle

Although I was able to fix the immediate problem by updating my own MCP server, I think there is still an important Codex Desktop robustness issue here.

In my case, I had access to the MCP server source code and was able to:

inspect the server logs;
identify the MCP Java SDK 2.0.0 Stateless handler bug;
update it to MCP Java SDK 2.0.1;
adjust the advertised MCP capabilities;
redeploy the server.

After doing that, Codex stopped freezing and even previously stuck conversations became usable again.

However, most Codex users will not necessarily have control over the MCP server they are using.

The MCP server could be:

a third-party hosted service;
a corporate/internal MCP managed by another team;
a vendor MCP server;
an outdated server implementation;
temporarily unavailable;
returning an invalid MCP/JSON-RPC response;
returning an unexpected HTTP 4xx/5xx response.

In those situations, the Codex Desktop client should ideally protect the main conversation lifecycle from the MCP failure.

The failure mode I observed was approximately:

Codex Desktop
      |
      | MCP capability probe
      v
Remote MCP server
      |
      | unexpected HTTP 500
      v
Codex conversation remains in busy/streaming state
      |
      v
follow-up messages cannot be sent

I think the preferable behavior would be something closer to:

Codex Desktop
      |
      | MCP request
      v
Remote MCP server
      |
      | error / timeout / invalid response
      v
Codex marks that MCP server/tool as unavailable
      |
      +--> surfaces an MCP error to the user
      |
      +--> resets the current turn state
      |
      +--> keeps the conversation usable

In other words, an external MCP server failure should probably not be able to leave the entire conversation permanently stuck in a streaming/busy state.

Some possible defensive behaviors on the Codex side could be:

treat MCP initialization/capability-discovery failures independently from the main conversation state;
ensure the turn is always transitioned out of streaming if an MCP request fails;
enforce a timeout around MCP initialization and tool/capability requests;
gracefully handle HTTP 4xx/5xx responses;
gracefully handle malformed or unexpected JSON-RPC responses;
mark the affected MCP server as degraded/unavailable;
allow retry/reconnect of the MCP server independently from the chat;
keep the composer enabled after the failed turn has been finalized;
surface the actual MCP error instead of leaving the UI spinner running indefinitely.

This seems especially important because an MCP client cannot assume that every connected MCP server is perfectly implemented or fully up to date.

There is also a related report in #29376 describing a similar principle: a failing remote MCP server should not block the core Codex Desktop conversation/thread workflow.

In my case, fixing the MCP server solved the immediate problem, but I believe Codex Desktop could still benefit from defensive isolation so the same class of MCP failure does not make the entire chat unusable for users who cannot modify the remote MCP server.

Recurrence after a brief recovery — 20 September 2026 (JST)

The normal Windows composer became usable briefly, but the same sending problem has returned. This is not a sustained fix.

Current Microsoft Store package: OpenAI.Codex 26.915.4065.0.

After reviewing the MCP-related workaround in this thread, we found a failing local Storyline MCP connection and disabled that connection through its supported configuration, preserving the configuration backup and all conversation data. This environment does not use the Java/Spring MCP server stack described above.

Observed sequence (JST / UTC+09:00):

00:12 and 00:14: two ordinary typed follow-ups in an existing short diagnostic conversation succeeded, including one after leaving the task and reopening it from Recent. The composer cleared and the replies appeared on the PC.
01:22: normal sending failed again: the text remained in the composer and the Send button kept spinning. Storyline was still disabled.
01:27: opening the same task in a separate app window produced the same failure. No new turn appeared.

The desktop logs inspected around the two failed submissions did not show a new turn/start for that conversation. Successful configuration and conversation-loading responses were present elsewhere in the same process. The exact blocked step and root cause remain unconfirmed; the brief improvement cannot be attributed conclusively to the MCP change.

Earlier in this case, typed messages through ChatGPT mobile Remote to the same PC-hosted task could continue the work when the normal Windows composer could not. This was not a separate mobile/cloud conversation.

No chat history, drafts, video assets, project data, or local databases were deleted. Please investigate the recurrence and provide a data-preserving recovery method or a confirmed fixed build. Has anyone else had normal sending work briefly and then fail again while the suspected MCP remained disabled?

Additional reproduction on Windows 11 / ChatGPT Desktop 26.903.61454.

Environment:

Windows 11 x64
ChatGPT Desktop / Codex & OWL: 26.903.61454
Release date shown in About dialog: 2026-09-09
Model used in Work: GPT-5.6 Sol

Observed behavior:

An existing Work conversation became unable to continue normally.
The composer accepted text, but the existing Work thread would not submit/continue correctly.
A brand-new Work conversation could send messages normally.
Codex in the same Windows desktop app could also send messages normally.
This indicates the account, network connection, and general desktop connectivity were still working.
After fully restarting the Windows desktop app, the same previously affected Work conversation became usable again and messages could be sent normally.

Important observation:

The failure was specific to an existing Work conversation/session.
New Work chats were functional.
Codex was functional.
A full app restart recovered the affected existing Work thread.

This looks consistent with a stale renderer/composer state or Work thread/session rehydration/resume problem rather than a general connectivity or authentication failure.

Expected behavior:
Existing Work conversations should remain able to submit follow-up messages without requiring a full desktop restart.

I also tried running codex doctor and codex login status in PowerShell, but codex was not installed / not on PATH on this machine. That appears unrelated to the desktop Work failure.

Screenshots are available showing:

the affected Work thread stuck after sending,
a new Work thread working,
About dialog with version 26.903.61454,
PowerShell showing codex command not found.

Additional reproduction: Windows 10, Desktop 26.915.31945 — 21 September 2026

The same follow-up submission failure is reproducible on this installation.

Environment

Windows 10
ChatGPT/Codex Desktop About version: 26.915.31945
Windows package: OpenAI.Codex_26.915.4065.0_x64
Bundled CLI: 0.155.0-alpha.9.2
ChatGPT Plus; model displayed: GPT-5.6 Sol (Medium)
In-app update check reports up to date.

Reproduction

Create a new Work/Codex conversation.
Send “你好” (hello). The assistant replies.
Send “只回复123” (reply only 123).
The text remains in the composer with a spinning send button; no second user message appears.

Both new and existing conversations are affected. Reopening the affected conversation after restarting the app did not recover sending in the latest test.

Troubleshooting already attempted

Uninstall/reinstall.
Rename the Roaming Codex desktop-state directory to a backup and relaunch. The failure recurred.
Change [desktop] followUpQueueMode from queue to steer, verify the saved value, restart, and test a new conversation. No improvement.
A standalone exec --skip-git-repo-check invocation of the exact bundled CLI successfully returned a short reply. This was a single-turn CLI control test, not a verified multi-turn CLI test.
Ordinary Chat mode was reported working.
The in-app feedback action did not respond.

Sanitized main-log excerpts from the new-conversation reproduction

Timestamps are UTC. Conversation identifiers are consistently replaced by A and B; omitted fields are not reproduced.

2026-09-21T04:01:25.386Z Conversation created
  conversationId=A threadId=A usedPrewarmedThread=true

2026-09-21T04:01:25.807Z Received turn/started for unknown conversation
  conversationId=B

2026-09-21T04:01:26.360Z response_routed
  conversationId=A method=turn/start errorCode=null

2026-09-21T04:01:26.724Z client.performance.span
  name=turn_first_response_visible outcome=success submissionKind=new_thread

2026-09-21T04:01:32.034Z Received turn/completed for unknown conversation
  conversationId=B

The captured log continues through 04:04:53 UTC without another turn/start after the failed follow-up attempt. It also contains Received broadcast but no handler is configured warnings for thread-stream-following-changed and thread-stream-following-status-requested.

These are observations, not proof that prewarming or the unknown-conversation events cause the failure: B may be an auxiliary thread. The exact root cause remains unconfirmed.

Please provide a confirmed fixed build or a data-preserving recovery method. Full logs, local usernames/paths, and raw session identifiers are intentionally omitted from this public report.

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

Windows Desktop 26.903.61454

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

After updating ChatGPT Desktop for Windows to version 26.903.61454 on September 9, 2026, I can no longer send follow-up messages in a conversation.

The issue affects both existing and newly created conversations:

In existing conversations, I can type into the composer, but the Send button remains disabled/gray. Clicking it changes the button to a spinner, but the message is never added to the conversation. In a newly created conversation, the first message sends normally and receives a response, but any subsequent message in the same conversation cannot be sent. The problem started immediately after updating to version 26.903.61454.

The web version of ChatGPT is not showing the same composer behavior, so this appears to be specific to the Windows Desktop client.

What steps can reproduce the bug?

Launch ChatGPT Desktop on Windows. Create a new conversation. Send the first message. Wait until the assistant finishes responding. Type a second message. Click the Send button.

Alternatively:

Open an existing conversation whose previous response has already completed. Type a new message. Click Send.

What is the expected behavior?

Once the previous turn has completed, the composer should return to an idle/enabled state and allow another message to be submitted normally.

Additional information

Relevant Log Evidence

There appear to be two related state inconsistencies.

Completed turns are restored as still streaming

When existing conversations are resumed, the Desktop client logs states such as:

latestTurnStatus=completed markedStreaming=true

This happens across multiple conversations.

This suggests that the app-server considers the latest turn completed, while the Desktop renderer still restores the conversation as streaming/busy.

That would explain why the composer remains disabled after the response has already completed.

No second turn/start is generated

For a newly created conversation, the first turn is submitted normally:

method=thread/start ... Conversation created conversationId=01a08531-3ff4-78f1-b9f3-a652dd06a48c ... method=turn/start errorCode=null

However, after reproducing the issue by attempting to send the second message, there is no second method=turn/start entry anywhere later in the log.

This suggests that the second Send action is getting stuck in the Desktop UI / renderer state before the request reaches the local app-server.

Unknown conversation lifecycle events

The same session also contains:

Received turn/started for unknown conversation conversationId=01a08531-419b-7e92-9ba0-e40c7138e4cf

and later:

Received turn/completed for unknown conversation conversationId=01a08531-419b-7e92-9ba0-e40c7138e4cf

The visible conversation created at the same time was:

01a08531-3ff4-78f1-b9f3-a652dd06a48c

I am not certain whether the 419b... conversation is an auxiliary/ephemeral thread, but it may be relevant to the renderer/conversation routing issue.

Additional Notes The local app-server initializes successfully. Authentication succeeds. The first turn/start succeeds. This does not appear to be a general connectivity failure. The failure is highly deterministic: first message works, follow-up messages do not. The regression started immediately after updating to 26.903.61454.

I can provide the full Desktop logs from the reproduction session if needed.

Additional reproduction on September 28, 2026: follow-up submission still stalls on Windows package OpenAI.Codex 26.924.2738.0 (internal release 26.924.22138, build 11645).

Read-only inspection confirmed:

The affected chat's previous response completed at 2026-09-27 23:12:24 UTC.
A desktop follow-up was saved at 23:20:04 UTC, almost eight minutes later.
It remained in persisted queued-follow-ups with submissionIntent="send-now", submission.status="pending", hostId="local", and queueModeOverride="send-now".
The chat API reported idle, with the prior turn completed and no new user turn.
No subsequent turn/start or turn/steer for that chat appeared in the inspected desktop log. Reads of the same chat still succeeded in 1–5 ms.
Another message in a different chat was also persisted as send-now/pending.
Mobile Remote remains the user's observed workaround.

At the matching submission time, logs recorded:

2026-09-27T23:20:04.770Z warning [IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate
2026-09-27T23:20:04.770Z warning [IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate
2026-09-27T23:20:04.771Z warning [IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed
2026-09-27T23:20:04.771Z warning [IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed

This establishes that desktop accepts/persists the message but fails to advance it into a backend turn. Ordinary queueing behind an active response does not explain this: the chat was idle and the message requested send-now. The missing-handler warnings are correlated evidence, not proof of the exact root cause. An unresolved local query, stale frontend state, dispatch ownership or a send lock remain hypotheses.

The user has experienced recurring submission failures across recent releases. A previously installed third-party Send-button repair targeted configuration loading, but its diagnostic attachment failed on this build; it did not establish the current cause. This was not a clean-profile A/B test. No queues/settings were reset or active work restarted during capture.

Related reports: #46590 and #44295. We have not proven they share the exact underlying defect.

Please investigate pending/send-now-to-turn dispatch and completion-to-idle reconciliation, provide a supported recovery path, and add regression coverage for consecutive messages after completion and desktop/mobile state convergence. A stuck submission should expose an actionable retry/error state instead of silently remaining pending. This repeatedly interrupts normal multi-turn work.

Private prompts, chat IDs, account details, workspace paths and raw log bundles are omitted.

Follow-up to my earlier report on Windows package 26.924.2738.0 / app 26.924.22138 (build 11645): restarting the renderer process appears to release the stuck messages and restore subsequent desktop submissions.

Observed by the user after the earlier capture:

Messages that had appeared stuck in the queue went through after restarting the renderer process.
Subsequent messages also worked; recovery was not limited to one queued message.
Mobile Remote had remained a working alternative before this recovery.

This is a user-observed recovery, not an instrumented before/after trace. We have not established how long it lasts, whether every queued item executed exactly once, or which pending request/readiness/ownership state the renderer restart cleared. It supports investigating desktop renderer state and submission reconciliation, but does not prove that the correlated missing-handler warnings caused the fault.

Please include renderer recreation and recovery of already-persisted send-now/pending messages in regression coverage, including subsequent consecutive submissions and protection against duplicate dispatch. Related exact-version queue report: #48550.

I know this isn't the place, but... one month of this. I'm really tired. I'm switching to Claude.

Resolved on my Windows machine by Store package 26.930.2377.0 (app release 26.930.21537, buildNumber 12776, bundled app-server 0.159.0-alpha.12.1), after ~20 consecutive failed launches on 26.908, 26.915, 26.928.2636.0 and 26.928.3736.0.

Worth knowing if you are bisecting: the working build ships app-server 0.159.0-alpha.12.1, a lower version string than the 0.159.2 in the broken builds, so version numbers alone will mislead you.

Also, every failing session here logged [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000 while the renderer never reached app routes mounted; the working build logs no such timeout.

Full timeline, the per-conversation counts from when only resumed chats were blocked, and the list of things that did not help (two clean reinstalls, app reset, empty sessions directory, Defender exclusions, stale config repair) are in #45187, most recently #45187 (comment). Posting here because this thread has the most affected users.

Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn #44102

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 9, 2026

sanzhang2 commented on Sep 9, 2026

gmehmetoglu commented on Sep 9, 2026

sanmugamsalecha-bot commented on Sep 10, 2026

Susan1433 commented on Sep 10, 2026

SIMON-WORLD commented on Sep 10, 2026

msgtechltd commented on Sep 10, 2026

cbcs commented on Sep 11, 2026

Rury233 commented on Sep 11, 2026

stracterr commented on Sep 11, 2026

7 remaining items

Yevhenii-ev commented on Sep 13, 2026

Yevhenii-ev commented on Sep 14, 2026

snilia commented on Sep 14, 2026

ksp1121 commented on Sep 15, 2026

huxaiver-byte commented on Sep 15, 2026

Windows Codex Desktop：第二条消息无限转圈、界面语言异常及完整排查记录

一、我遇到的问题

二、在这次详细排查前，我已经做过什么

1. 检查全局状态及其备份

2. 在 Codex 内置任务管理器结束备用渲染程序

三、AI 在本机检查到了什么

四、我配合进行的第一次定时测试

15:56：在已有聊天点击第二次发送

本次还发现的状态差异

五、我配合进行的第二次独立测试

六、我配合退出应用，尝试调试启动

七、我手动重新打开后，界面和发送恢复

八、哪些结论需要修正或保留

九、我最终的使用选择

faelp22 commented on Sep 17, 2026

Update: I found the cause in my case

Previous configuration

MCP Java SDK bug

What I changed

Result

Maven note for Spring AI 2.0.1 users

Important clarification

Possible Codex-side robustness issue

faelp22 commented on Sep 17, 2026

Additional observation: Codex should probably isolate MCP failures from the conversation lifecycle

tajayuki1111-blip commented on Sep 19, 2026

Recurrence after a brief recovery — 20 September 2026 (JST)

Pretic commented on Sep 21, 2026

xx0-hue commented on Sep 21, 2026

Additional reproduction: Windows 10, Desktop 26.915.31945 — 21 September 2026

QifengWu-2001 commented on Sep 21, 2026

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

xennon101 commented on Sep 27, 2026

xennon101 commented on Sep 28, 2026

pleiadess commented on Sep 29, 2026

sinec09-cloud commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions