Activity

1. Theeeus

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Sep 13, 2026
3. github-actions commented on Sep 13, 2026

   

   github-actionsBot

   on Sep 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows desktop: recurring missing integration entries, marketplace path failures and intermittent prompt submission failure (26.908) #45138
   • Codex desktop (Windows): follow-up messages in existing threads never send #45069
   • Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur #44342
   • Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn #44102

   Powered by Codex Action
4. Ph3n1xaX commented on Sep 13, 2026

   

   Ph3n1xaX

   on Sep 13, 2026

   More actions

   Windows desktop 26.908.40834: Send spins forever in every reopened conversation (no turn/start emitted); new conversations work; app-server healthy

   Environment

   App	Codex desktop, Microsoft Store package 26.908.4834.0 (app 26.908.40834)
   Bundled app-server / CLI	0.154.0-alpha.6.2
   OS	Windows 11 IoT Enterprise LTSC 2024, build 26100, x64
   Auth	ChatGPT sign-in
   Started	Right after the automatic update on 2026-09-12

   Summary

   In any existing conversation, pressing Send puts the arrow into an endless spinner. The message never appears, no task starts, and the text stays in the composer.
   A brand-new conversation sends and completes normally.
   The app-server itself is healthy: when Send is pressed in a reopened conversation, the client never sends turn/start.

   Steps to reproduce (100% reproducible on this machine)

   1. Launch the app.
   2. Open any existing conversation from the sidebar.
   3. Type test and press Send → spinner forever, nothing is sent.

   Control: create a new conversation, type test, press Send → reply in ~8 s.

   Tested on three existing conversations (rollout sizes 0.2 MB, 146 MB and 419 MB), with and without a leftover draft: all fail the same way.

   Evidence from the app-server logs (logs_2.sqlite, TRACE level)

   New conversation (works)

   • thread/start → turn/start received about 1 s later
   • turn/started, item/started, item/agentMessage/delta, item/completed and turn/completed are all delivered to the client (targeted_connections=1)

   Reopened conversation (fails)

   • thread/resume completes in under 1 s: session init, MCP init and the /responses websocket connect with no errors
   • Pressing Send afterwards produces no turn/start request at all. Nothing reaches the app-server, and nothing is logged for the attempt.
   • The only events sent to the client after the resume are warning and thread/goal/cleared
   • History pages (thread/items/list, thread/turns/list) load in under 1 s and stop, so this is not a pagination loop

   Before the reinstall (2026-09-12 evening)

   • Three turn/start requests for an existing conversation were received, but produced nothing: no turn, no turn/started, no error

   During the hang

   • The app-server process is idle (0% CPU, all threads waiting)
   • The follow-up queue DB is empty
   • The desktop log files in the package LocalCache\Local\Codex\Logs\ are 0 bytes, so no renderer-side trace is available

   Engine sanity check

   • codex exec --ephemeral, with the same CODEX_HOME and the same account, returns a reply in 8 s

   Ruled out

   • OpenAI status page: all operational
   • Authentication: ChatGPT auth works (new conversations and the CLI succeed). Signing out and back in gave no lasting fix.
   • MCP servers failing their handshake: disabled them, no change
   • Full restart of the app, and uninstall + reinstall from the Store (the same build gets reinstalled): no change
   • Multiple instances: only one desktop app and one app-server running, no VS Code or other Codex clients
   • config.toml: parses OK, no third-party extension entries
   • Conversation size, leftover drafts, per-thread settings: approval policy, reviewer and sandbox settings are identical between the working new conversation and the failing ones
   • Ctrl+R / Ctrl+Shift+R in the main window (the workaround from Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur #44342) does not reload the renderer on this build. No initialize and no startup burst appear in the app-server logs, so that workaround could not be applied.

   codex doctor (summary)

   • config loaded, parse OK; auth configured (chatgpt)
   • state, log, goals, memories, queue and thread-history DBs: integrity OK
   • ⚠ threads: 2 issues
     • "rollout files are missing from the state DB" (4 active rows missing)
     • "duplicate thread inventory entries found" (3 duplicate rollout thread ids)
   • ⚠ Microsoft Defender exclusions not verified
   • ⚠ bundled rg.exe not found

   Other observations (possibly related)

   • Every thread/resume logs unknown feature key in config: thread_tools. That key is not in the user config.toml, nor in any rollout file.
   • experimentalFeature/enablement/set logs ignoring invalid experimental feature enablement keys: apps_mcp_path_override, local_thread_store_compression. This suggests a feature-flag mismatch between the desktop client and the bundled app-server.
   • The update ran the rollout migration legacy_to_paginated_v1 and state DB migrations v53 (threads originator) and v54 (threads daybreak enabled) on 2026-09-12.
   • thread/resume logs dropping turn-scoped item for unknown turn id warnings.
   • A background memory-consolidation turn repeatedly failed apply_patch with invalid hunk ... Expected update hunk to start with a @@ context marker, got: 'NaN'.

   Workarounds

   • ✅ Start a new conversation: works
   • ✅ The CLI engine works (codex exec). codex resume on an existing conversation was not tested.
   • Reported in Windows Codex desktop: Send button spins forever and prompts never submit #40968 (not verified here): sending to an affected conversation from ChatGPT remote/mobile works

   Related issues

   #40968, #44342, #45174, #44102
5. mower07 commented on Sep 30, 2026

   

   mower07

   on Sep 30, 2026

   More actions

   Additional Windows reproduction on a newer build, with local persistence/queue checks (2026-09-30).

   Environment: Windows 10 build 10.0.19045 x64; installed MSIX OpenAI.Codex 26.928.2636.0; desktop log buildNumber 12404; desktop child executable reports codex-cli 0.159.2.

   Observed sequence:

   1. An existing local conversation finished its previous turn normally at 12:50:26 UTC.
   2. The user entered a follow-up and clicked Send.
   3. The send-arrow control stayed on a processing spinner. The user could not copy the pending text through the composer. There was no usable error/retry outcome.
   4. Read-only inspection showed the previous turn completed, with no new turn recorded. The persisted rollout ended with task_complete for the previous turn.
   5. A read-only query of queue_1.sqlite found no queued_items row for the affected thread at inspection time. This is a point-in-time observation, not proof that no transient queue entry ever existed.
   6. The full 1,294-character follow-up was still present in .codex-global-state.json under composer-retained-documents-v1 and matched the latest prompt-history entry. A composer draft document was also present. The text was recovered into a separate local file and its equality verified before restarting.

   The available evidence places the visible stall before a new recorded turn; the exact failing request, root cause and deterministic trigger are unknown. No claim is made that the model was processing the message. Private message content and thread identifiers are omitted.

   Restarting Desktop then encountered the separate cold-start loading issue described in #48466. Restarting only its verified idle child app-server restored the app, and the user confirmed it opened. This does not establish that resending the original message succeeded; that has not been verified.

   Expected: either durably accept the follow-up or return a bounded, actionable error. Preserve access to Copy/Save draft and provide a recoverable retry/cancel path while submission is pending. Reconcile uncertain delivery against canonical history before replaying, to avoid duplicate submission. Please investigate why the composer can remain indefinitely pending while neither a new turn nor a durable queue row is visible.

   No database, history or configuration was modified as part of diagnosing the send failure, and no private prompts or full logs are attached.