Codex desktop (Windows): follow-up messages in existing threads never send

[I-shang-I]

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

26.908.40834

What subscription do you have?

Pro

What platform is your computer?

Windows 11 Home, build 26200 (x64); the machine is behind a TLS-inspecting proxy, but the proxy is not involved

What issue are you seeing?

Symptoms

1. A new chat's first message sends normally. Every later message in that thread, and any message in an existing thread, spins forever. The text stays in the composer.
2. No request reaches the app-server. The desktop logs show no turn/start, turn/steer or thread/queue/add, and no error.
3. Sending to the same thread from the ChatGPT mobile app (remote control) works.
4. Sending through the in-app send_message_to_thread tool also works.
5. None of these helped: restarting the app, re-login, clearing the Electron Cache, Code Cache and GPUCache, switching followUpQueueMode between queue and steer, changing the model or permission mode, or using a different project folder.

Root cause analysis (runtime evidence)

The app was launched inside its package with --remote-debugging-port bound to 127.0.0.1. Non-pausing logpoints were set in webview/assets/app-primary-17b54400f32a.js and app-initial-d9bed9d614d8.js. The minified names below are from this build.

1. The composer submit gate parks the message. At the start of Evr's submit handler the state was {submitDisabled:false, submitting:false, submitBlockReason:"loading-local-config"}. yvr.queueSubmit then queued it with isLocalConfigPending:true. None of the later steps ran (cvr, the turn coordinator, turn/start).

2. Why isLocalConfigPending is true. Ygr() ends with composerMode==='local' && (localWorkspaceMaterialization==='loading' || …). The submit block context was:

   agentMode: guardian-approvals, isAgentModeLoading: false, isAgentModePending: false,
   windowsSandboxRequirement: null, isWindowsSandboxRequirementPending: false,
   localWorkspaceMaterialization: "loading", composerMode: "local", roots: ["D:\\Claude\\Kova"]
   

   Every other input was ready. The config/read, host and cwd data used by pvr() were all cached.

3. Why materialization is loading. The D8 query options (managed-worktree-state) read TC = ["vscode","codex-home",{hostId}]. Because TC has no data and no error, D8 returns a disabled query keyed codex-home-loading. aQo then maps "no data" to "loading" indefinitely. Live query cache:

   ["vscode","codex-home","{\"hostId\":\"local\"}"]  status=pending fetchStatus=fetching fetchFailureCount=0 error=null
   ["vscode","codex-home"]                          status=pending fetchStatus=fetching fetchFailureCount=0 error=null
   ["git","local","managed-worktree-state","codex-home-loading","D:\\Claude\\Kova"]  status=pending fetchStatus=idle
   

4. The startup codex-home request is never answered.

   • The renderer fetch client (sS.getInstance(), the vscode://codex/* bridge) still held 11 unresolved entries in pendingRequests about 30 minutes after launch.
   • The main process logged [electron-fetch-handler] codex-home request only during startup (six lines between +1.1 s and +14 s).
   • A fresh post('vscode://codex/codex-home', {"hostId":"local"}) from the same renderer returned in 2 ms with {"codexHome":"C:\\Users\\User\\.codex","worktreesSegment":"C:\\Users\\User\\.codex\\worktrees"}. The main handler (readCodexHomePaths) itself works; only the startup requests are lost.

5. Why it never recovers. TanStack Query's Query.fetch reuses the in-flight retryer when state.data === undefined, even with cancelRefetch: true. Invalidation and refetch therefore keep waiting on the lost promise. There is no timeout on the bridge request.

6. Confirmation. Running queryClient.cancelQueries({predicate: codex-home}) and then refetchQueries(...) turned both queries to success. D8 switched to ["git","local","managed-worktree-state","available",...], and the next desktop submit in an existing thread sent turn/start successfully (2026-09-12T15:48:34Z, conversation 01a0959a-…). This was the first one since 2026-09-11 16:18.

Startup timing correlation (not proven causal)

Times are milliseconds after Launching app:

Launch	Result	First codex-home requests	First query-cache-invalidate broadcast
2026-09-09	works	+3537, +3542	none in the first 40 s
2026-09-11 14:01 (d61b04e1)	works	+8872, +8905	+23185 (after avatar overlay loaded)
2026-09-11 16:35 (bbafcf82)	fails	+5219, +5237	+8568
2026-09-12 21:15 (430813af)	fails	+2565, +2573	+2893
2026-09-12 23:13 (4c766004)	fails	+2395, +2407	+3389

In every failing launch, an IPC query-cache-invalidate broadcast arrives about 1 s after the main window's first codex-home requests. It shows up in the main log as [IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate. In the working launches it arrives much later or not at all during startup. This may be how responses get lost or mis-routed, but it has not been proven.

Ruled out

• App-server: healthy. One codex.exe, fast responses, no queued items, SQLite quick_check ok.
• Stream ownership and resume: the thread was resumed and this window was the owner.
• Other submit gates: the goals feature (no goals), Windows sandbox readiness, and agent-mode or model-settings loading were all ready.
• Remote-workspace gate: it would show a dialog, not a spinner.
• Thread cwd: the \\?\ prefix and the specific project folder make no difference.
• Machine environment: WSL (healthy), proxy or TLS, stale helper processes, OS updates.

What steps can reproduce the bug?

Feedback ID: 01a0959a-8824-7282-9ac2-59173f451f2d

What is the expected behavior?

Able to submit prompt to the previous session.

Additional information

Suggested fixes

1. Add a timeout and retry to vscode://codex/* bridge requests, or reject pending requests on any window or IPC reset. Unanswered bridge requests should never hang forever.
2. For codex-home, handle a stuck initial fetch with no data: cancel it, then refetch, instead of relying on cancelRefetch.
3. Do not block the composer indefinitely when localWorkspaceMaterialization is loading. Fail open or show an actionable error after a timeout.
4. Log bridge requests that stay pending longer than N seconds, with their URL, so this is visible in the desktop logs.

Workaround in use

Launch Codex with --remote-debugging-port=<port> via Invoke-CommandInDesktopPackage, then cancel and refetch the stuck codex-home queries through DevTools. This lasts only for that app session.

[github-actions]

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

• 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
• [Windows Desktop] Second message stalls after first turn completes #44295

Powered by Codex Action

[lishuoipad]

Confirmed the cancel-then-refetch codex-home recovery on Windows package 26.908.4834.0 on September 13, 2026 (UTC+8), with two completed follow-up replies through the normal desktop composer.

Full runtime observations, recovery steps, core query-retry code, cleanup and limitations: #44342 (comment)

In an idle existing conversation, the actual main window (type=window, exact URL app://-/index.html) reported isResponseInProgress=false, isResumePending=false, submitBlockReason=loading-local-config, and localWorkspaceMaterialization=loading. Both home-query variants were pending / fetching with no data or error.

Using a temporary loopback-only diagnostic connection to the already-running desktop main process, cancelling those exact two queries and then refetching them returned actual directory metadata. Both became success / idle, workspace materialization became available, and the configuration submit block cleared. No restart, main-window reload, Ctrl+R, readiness override, permission change or cache/data reset was used.

Validation in the same existing conversation:

1. Typed a short follow-up in the normal composer, clicked Send, and observed a complete reply.
2. Closed the diagnostic interface and verified the listening port was gone. After the first reply had completed, typed another follow-up in the same composer, pressed Enter, and observed another complete reply.

Desktop main-process and app-server PIDs/start times were unchanged, and the original unsent draft was restored afterward. Neither test was submitted via send_message_to_thread or another messaging tool. markedStreaming=true was not treated as proof of an active turn.

This establishes recovery for this session, not a permanent fix. Eight other local initialization reads still showed pending / fetching and were not retried; they did not prevent these sends. The original startup response-loss boundary remains untraced, and recurrence after another ordinary launch remains possible. A supported bounded recovery path is still needed.

[MiraScully]

I can reproduce this on Codex Desktop for Windows, version 26.908.40834.

Additional UI behavior that may help narrow it down:

• In a new chat, the first message sends normally.
• After the first response, I can type a follow-up, but the Send icon looks faded (similar to an empty composer) while still remaining clickable.
• Clicking Send starts the spinner, but the message is never added to the conversation and no task starts.
• If I switch to another chat and then return, the spinner is cleared and the draft is still visible, but it was not sent.
• Retrying Send after switching chats produces the same behavior again.
• Existing chats are affected as well.

So switching chats appears to reset only the visible loading state, not the underlying submit problem.

[MiraScully]

Additional workaround observation on Windows Desktop 26.908.40834:

Using the built-in Chromium/Electron task manager and terminating the Renderer process that owns the main Codex window caused the window to briefly turn white and the renderer to restart automatically. After that, sending from an already affected existing chat worked again.

This is not just a one-message recovery: after the renderer restart, multiple subsequent follow-up messages have continued to send normally so far without having to repeat the restart after each response. I do not yet know how long the recovery lasts.

There are multiple Renderer entries in the task manager, so the relevant one is not obvious by name alone. The useful signature is that terminating the correct Renderer causes the whole main Codex chat window to go white briefly and rebuild. I did not need to terminate the Browser process.

This appears to be a much simpler user-facing workaround than launching with a remote debugging port and calling webContents.reload(), and seems consistent with the existing evidence that a main-window renderer reload clears the stuck state.

[yunuseli]

Temporary recovery confirmed twice — Windows 26.908.4834.0 / About 26.908.40834.

Symptoms: A new task accepts its first message, but the second and subsequent normal composer messages do not send; existing tasks are affected too. Internal task-to-task messages (send_message_to_thread) and replies to asynchronous question cards still work. This blocks normal work across tasks despite those alternative paths remaining functional.

Follow-ups stopped because two codex-home queries stayed pending/fetching (no data/error), leaving the composer at loading-local-config.

For Codex-assisted recovery: inspect the running main window (type=window, exact URL app://-/index.html). Obtain its existing React/TanStack QueryClient (qc; not a new instance or guaranteed global). Only with the matching signature:

const keys = [
  ["vscode", "codex-home"],
  ["vscode", "codex-home", JSON.stringify({hostId: "local"})]
].map(k => JSON.stringify(k));
const targets = qc.getQueryCache().getAll().filter(q =>
  keys.includes(JSON.stringify(q.queryKey)) &&
  q.state.status === "pending" && q.state.fetchStatus === "fetching" &&
  q.state.data === undefined && q.state.error == null
);
if (targets.length !== 2) throw Error("Different signature; stop and diagnose");
const hashes = new Set(targets.map(q => q.queryHash));
const filter = {predicate: q => hashes.has(q.queryHash)};
await qc.cancelQueries(filter);
await qc.refetchQueries(filter, {throwOnError: true});

Verify success/idle, workspace available, the submit block cleared, and normal composer follow-ups. Close temporary diagnostics afterward. Build-specific diagnostic access details.

Fully quitting and reopening Codex reproduced the same fault. Repeating this recovery restored normal sending again. The user confirmed both recoveries through normal composer messages.

No restart/reload during recovery, history/config reset, database/bundle edits, or readiness/permission bypass. Do not retry all pending requests; some are writes. This recovers the current session; a permanent startup/timeout fix is still needed.

[zhangzexin]

Additional observed occurrence on September 14, 2026, with matching live query/composer state.

Environment: Windows x64 packaged Codex Desktop; package version 26.908.4834.0, reported client version 26.908.40834, bundled backend 0.154.0-alpha.6.2. A custom model provider was configured; provider credentials and identifying details are omitted.

Observed flow: the initial message in a new conversation worked, but subsequent messages could not be submitted. The send control appeared grey/unresponsive; the loading appearance could disappear without restoring submission. This affected multiple conversations. Restarting alone did not reliably resolve it, and there was no actionable error.

Live state during failure:

hasMessageContent = true
isResponseInProgress = false
submitDisabled = false
HTML send button disabled = false
submitBlockReason = loading-local-config
disabledReason = 正在加载… (Loading…)
localWorkspaceMaterialization = loading

["vscode","codex-home","{\"hostId\":\"local\"}"] : pending / fetching
["vscode","codex-home"] : pending / fetching
["git","local","managed-worktree-state","codex-home-loading","<workspace>"] : pending / idle

Recovery evidence:

• Cancelling the two stalled codex-home queries and refetching actual directory data returned valid paths, changed workspace materialization to available, and cleared the submission block. Actual follow-up test messages then completed successfully in both affected conversations.
• Reloading the main renderer after backend startup, keeping the backend running, also restored workspace readiness. This is a diagnostic workaround, not a permanent application fix.
• Temporary local debugging listeners were closed afterward. No conversation deletion or forced readiness flags were needed.

Other checks: the preceding turn had completed; the queue was empty; permissions and sandbox readiness were normal; account usage allowed ordinary requests. Removing a standalone CLI override and using the bundled backend did not prevent recurrence. An IDE-context spinner was not the cause of the configuration block.

These observations corroborate the indefinitely pending local-configuration prerequisite. They do not establish the exact point where the original startup request/response failed, or prove a specific startup race.

Please add bounded completion/failure and safe retry for these idempotent initialization reads, plus an actionable composer error/retry path that preserves drafts. A regression check should cover new-chat first send followed by follow-up sends, and normal startup versus renderer reload.

This supplement excludes conversation contents and IDs, account details, user-specific filesystem paths, credentials, and raw logs.

[blxckhundred]

Additional workaround observation on Windows Desktop 26.908.40834:

Using the built-in Chromium/Electron task manager and terminating the Renderer process that owns the main Codex window caused the window to briefly turn white and the renderer to restart automatically. After that, sending from an already affected existing chat worked again.

@MiraScully May I ask how you managed to open Task Manager? I have the same version and the same problem as everyone else here, but I can’t even open Task Manager - Shift+Esc doesn’t work, even after I removed the action assigned to that key combination in the settings. So far, the only thing that helps is logging out and logging back in.

UPD: found it, It's hidden in the buttons at the top.

[whtpdbs0204]

I can independently reproduce what appears to be the same Windows Desktop follow-up submission failure on a newer build.

Environment

• Codex App (About dialog): 26.915.31945
• Windows 11 25H2
• Build: 26200.9457
• x64
• Windows sandbox: unelevated
• Home network / personal PC
• VPN installed but not active
• Manual proxy disabled
• Session ID: 01a0b7bb-7603-7542-b6b7-bdb0590d7eed

User-visible behavior

In both Codex and Work:

1. A new conversation can submit the first message normally.
2. The first response completes normally.
3. After typing the second message, the send arrow appears gray.
4. Pressing Enter once changes the composer button to a spinner.
5. The draft remains in the composer.
6. The second user message is not added to the conversation body.
7. Navigating away and returning removes the spinner, but the draft remains and the send arrow is gray.

The same behavior reproduced with Blender MCP disabled and confirmed absent from the new runtime, so Blender MCP does not appear to be the primary cause.

Backend evidence

For the affected second submission I observed:

• no second turn/start
• no second turn/steer
• no second task_started
• no stored second user message

The first turn completed normally.

This is consistent with the request being blocked before backend acceptance.

Performance Trace evidence

I collected a trace using the public ChatGPT Desktop:

Help → Start Performance Trace

feature.

For the failed second Enter, an actual V8 CPU sampled stack showed:

DOM keydown → editor Enter handler → composer submit → local-config queueSubmit / queueLocalConfigSubmit → React state setter

So the second Enter definitely reaches the local-config queue path.

However, the trace did not directly expose:

• hasPendingSubmit
• submitBlockReason
• W2e readiness values
• queue return value
• React setter boolean argument

I also did not observe a second U3e/preflight sample. Because short/async functions may be missed by CPU sampling, I am not treating that absence as proof that U3e never ran.

After the failed Enter, the renderer was mostly idle, with no evidence of a persistent CPU busy loop. This makes a readiness/state update or queued-submission release problem more plausible than CPU starvation.

Relation to this issue

My trace independently confirms entry into the same local-config submission-queue area described here, but I have not directly measured a stuck codex-home query on my machine, so I cannot claim that the exact root cause is identical.

Static inspection of the current installed build suggests the follow-up materialization path can depend on codex-home / workspace readiness before submission, which is consistent with the mechanism described in this issue.

I have a ~630 MB raw Performance Trace and the affected session transcript available locally. I have not uploaded them publicly because they may contain local/sensitive diagnostic data. I can provide them if maintainers want a specific supported transfer method.

[yunuseli]

Update, 19 September 2026: still reproducible after updating; additional confirmed queue-read blocker.

Follow-up to my earlier recovery report.

Impact: This has repeatedly interrupted daily work since September 11–12. A new conversation's first message can work while normal follow-ups/existing conversations cannot send; internal task-to-task messages and question-card replies still work. The user also reports losing the ability to send corrections or stop work during active tasks and having to quit the app. The Stop failure itself has not yet been independently traced; it should not be assumed fixed by the send recovery below.

A. Reproduced today on Windows package 26.915.4065.0, About 26.915.31945. Both codex-home query variants were pending/fetching, without data or error; workspace materialization was loading and the composer block was loading-local-config. At 06:45:43 UTC, cancelling and refetching exactly these two reads through the existing QueryClient returned real data: both success/idle, workspace available, block empty-message. Normal user follow-up messages subsequently arrived in the same task. No app/renderer restart, history/database/cache reset, permissions change, or installed-bundle modification was performed. The same startup fault has recurred across launches and updates.

B. Separately verified on September 18, package 26.915.3509.0, About 26.915.31029: a stale thread/queue/list blocked sending during ongoing work.

• One initial queue-list request started at 16:15:28.800 UTC. Main-process logs recorded the same request ID as response_routed after 9 ms, errorCode=null, hadPending=true, targetDestroyed=false.
• Roughly 82 minutes later, the real renderer AppServerManager request client still held that request's unresolved promise.
• Installed-source inspection showed that the queue loader retains the in-flight initial read per thread; enqueue awaits it before reaching thread/queue/add. Merely clearing the visible submitting flag enabled the button but did not unblock this dependency.
• A fresh, read-only queue-list request returned actual current data. With the original request identity/method/thread still verified, completing its normal onResult path with that actual response released the already-clicked original submission. No replacement user message or direct queue-add was issued.
• At 17:37:40.164 UTC, the original submission produced a successful thread/queue/add; an independent subsequent queue read confirmed one persisted queued message. This confirms enqueue, not execution/completion of that message.

This establishes a concrete blocking chain, not the precise cause of the original response loss: response_routed alone does not prove renderer delivery/handling. The queue-read recovery is build-specific diagnostic work, not a supported general patch; do not fabricate successful responses, replay tool/write requests, or clear all pending requests.

Request to maintainers: Please triage this as a work-blocking Windows issue, including loss of timely intervention during active work. A supported recovery path and bounded timeout/retry for safe reads would avoid indefinite composer locks. Please also investigate the response-delivery/completion gap and stale per-thread queue-load promises. Can you confirm whether a fix is in progress or which desktop build contains it?

Only sanitized technical observations are included here; no project contents, private paths, or raw traces are attached.

[jiangzengyuang-jisoo]

Independent confirmation on Windows, 19 September 2026: package 26.915.4065.0, bundled app version 26.915.31945.

The user reported that most existing conversations could not send follow-ups and that the problem had returned after a recovery the previous day. Today's occurrence was inspected directly; the observations below are from this machine.

Captured failure

Existing conversations resumed, but clicking Send entered the local-configuration wait path without reaching actual turn submission:

submitBlockReason = loading-local-config
localWorkspaceMaterialization = loading
isResumePending = false
isSubmitting = false

["vscode","codex-home"]
["vscode","codex-home","{\"hostId\":\"local\"}"]
  status = pending
  fetchStatus = fetching
  dataUpdatedAt = 0
  fetchFailureCount = 0

A fresh read of the same directory metadata succeeded immediately. Cancelling and then refetching only these two queries through the existing QueryClient returned real directory data. Both became success / idle; workspace materialization became available.

Recovery and verification

• Before any renderer reload, three follow-up replies completed through the desktop composer across two existing diagnostic conversations.
• A later inspection still found seven unresolved renderer bridge requests, while the inspected host fetch registry and chunk sender queue were empty. This is evidence of stale client waits, not proof of where the original responses failed.
• A subsequent instrumented renderer reload recorded 35 distinct local requests, 35 host responses and 35 renderer receipts, matched by request ID, with no missing response in that reload.
• After removing instrumentation, a second renderer reload left zero pending bridge fetches. A fourth composer follow-up completed at 2026-09-19 08:34:00 UTC, and the composer remained editable.

No installed-bundle patch, conversation deletion, database reset, or permission/readiness override was used. Temporary diagnostic hooks and the loopback debugging listener were removed. These results establish session recovery; whole-process cold restart, sleep/wake, and deterministic fault-injection regression tests were not completed.

Implementation observations and requested durable fix

In this installed build, Rv.sendRequest in app-initial-6c4523b43a11.js registers vscode://codex/ requests without an intrinsic timeout. The W2e / n6e / o6e paths in app-primary-355549b35da9.js retain the local-config submission wait.

Please investigate startup response completion and add bounded timeout/cancellation plus limited retries for the safe directory reads. On terminal failure, the composer should end the wait, preserve the draft and provide an actionable retry without bypassing readiness checks or duplicating message submissions. Please confirm whether a supported fix is planned or which desktop build includes it.

Only sanitized observations are included: no account details, conversation IDs/content, private filesystem paths, credentials or raw logs.

[yuzhe2026ai-cmyk]

I can reproduce this issue too.

Environment:

• Windows desktop app
• ChatGPT Pro account
• Work mode

Symptoms:

• First message in a new conversation works normally.
• After the first response completes, the second message cannot be sent.
• The message stays in the composer and no new response starts.

Comparison:

• Chat mode works normally.
• Web version works normally.

I have submitted OpenAI feedback reports:
01a0c4fd-161c-7c43-925d-5ca5f4f05353
01a0ca02-4e87-7b00-af16-d042bf6712ba

This issue has happened repeatedly over multiple days.
It would be helpful to know if this is a known Windows desktop client bug.

2026/09/24：
I can reproduce this issue too.

Environment:

• Windows desktop app
• ChatGPT Pro
• Work mode

Symptoms:

• First message works normally.
• After the first response completes, follow-up messages cannot be sent.
• Chat mode and Web version work normally.
• Codex CLI works normally.

Additional observation:
The issue temporarily disappeared after reinstalling Clash (proxy client), but returned the next day while using the same environment.

This makes me suspect the proxy/network state may be a trigger, but the root cause may still be related to the Windows desktop client session handling.

OpenAI feedback IDs:
01a0c4fd-161c-7c43-925d-5ca5f4f05353
01a0ca02-4e87-7b00-af16-d042bf6712ba