我个人观察到的现象是，会话创建后的首条消息正常，之后的消息会延迟数秒才能发出，在 mac 和 windows 平台都出现了此问题；
并且 mac 版本还出现了运行时 cpu 使用率过高，发热严重的问题。
github 上也有不少类似的反馈，首个发现的版本应该是 26.415.21839；有人反映关闭记忆功能后可绕过此问题，但对大多数人包括我自己无效，目前只能通过降级解决。
JavierPiedra
bug
app
session
### What version of the Codex App are you using (From “About Codex” dialog)? 26….415.21839 ### What subscription do you have? Pro ### What platform is your computer? Darwin 25.3.0 arm64 arm ### What issue are you seeing? ## Summary In the Codex desktop app, sending a message can take around 8 seconds before the message is actually sent. This appears to have started after the latest update. It did not happen in older sessions before. ## Environment - App: Codex desktop app - Codex version: `26.415.21839 (1763)` - macOS: `26.3.1 (build 25D771280a)` - Hardware: `MacBook Air (Apple M3, 24 GB RAM)` ## Actual behavior After pressing Enter to send a message, the message does not send immediately. Observed behavior: - The spinner appears in the send button - The message remains pending for about `8 seconds` - Lowering reasoning does not help This is affecting sessions created after the latest update. ### What steps can reproduce the bug? ## Reproduction Observed repro: 1. Open Codex desktop 2. Open a newer thread created after the latest update 3. Type a normal message 4. Press Enter 5. Observe the spinner in the send button and a delay of about `8 seconds` before the message is sent Additional observation: - In a brand-new thread, the first message sent immediately - The second message in that same new thread then started taking a very long time to send ## Scope / pattern - Happens in newer sessions created after the latest update - Did **not** happen in older sessions tested by the user - Not fixed by lowering reasoning - Seen with `GPT-5.4` and `Extra High`, but reasoning level does not appear to be the cause ### What is the expected behavior? ## Expected behavior Pressing Enter should enqueue and send the message immediately, or at least show near-instant client acknowledgment. ### Additional information ## Notes This feels like client-side send latency rather than raw network latency. Local diagnostics from the machine at the time: - Network path looked healthy in macOS logs - Codex renderer/helper processes showed noticeable CPU activity while the issue was occurring - No obvious network failure was visible from the local system logs ## Impact This makes normal back-and-forth use of Codex frustrating because even short messages feel blocked before they are sent. If you want, I can also compress this into a shorter GitHub-style version, or turn it into a more technical issue with a small `Additional diagnostics` section at the end.
本以为是梯子又出问题，但看了下发现是 app 的锅，记录一下
9 个帖子 - 8 位参与者