Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur

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

Windows package 26.903.8094.0; internal app 26.903.61454 (recorded in prior diagnostics). See evidence and measurement dates below.

What subscription do you have?

Not disclosed for privacy; account identifiers and billing information are omitted.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary and impact

The Windows Codex desktop app repeatedly prevents follow-up messages from being submitted in existing chats. The composer remains blocked on local configuration/workspace preparation without an actionable error. New-chat initial messages can work, while follow-ups fail; even a newly created chat can subsequently be affected. During an earlier affected episode, messages sent through mobile Remote succeeded and appeared live on the PC.

This interrupts normal use of existing conversations and forces repeated manual recovery. Please investigate a permanent fix for the initial request-completion failure and add bounded recovery and a visible retry path. Creating another chat or asking users to reset their data is not an adequate resolution for this failure mode.

This report consolidates local diagnostic records from September 9 and a directly observed recurrence and recovery on September 10, 2026. Historical observations are identified below. The precise startup trigger and first missing-response boundary remain unconfirmed.

Additional history reported by the user (September 10 update)

The same user-visible sending symptom had already been observed approximately two weeks before this report (around late August 2026), not only on September 9–10. The exact first-occurrence date and app version from that time were not recorded here.
At that earlier time, resetting the .codex folder restored sending, according to the user. The symptom later recurred; the reset therefore did not establish a permanent fix. The exact reset procedure and which files changed were not documented in this report.
The user also reports that the symptom recurred on another PC. This is user-reported cross-PC occurrence; the detailed internal-state measurements in this report were collected on one PC, and matching internal state on the other PC has not been independently verified.

These historical observations should inform the investigation, but they do not prove that .codex data corruption caused the problem or that every occurrence shared the same underlying cause. Please investigate why resetting local state helped temporarily and why the symptom can recur across PCs, while preserving user data in the supported fix.

Actual state and evidence

Earlier diagnostics (September 9)

The affected composer reported:

submitBlockReason = loading-local-config
localWorkspaceMaterialization = loading
isSubmitButtonLoading = true
codex-home query = pending / fetching

The renderer contained 12 incomplete local requests in the recorded recurrence. They included codex-home and other initialization reads such as language, automation-list, and shortcut state.
At that observation point, the main-process response queue / active lookup lists did not show corresponding outstanding work; a response sender object had targets: [].
A fresh request for the same codex-home information succeeded. One diagnostic record measured approximately 0.7 ms with a local HTTP-style status of 200; another recorded approximately 1 ms for both normal and priority response routes. These were local bridge timings, not external-network measurements or a performance benchmark.
App-server initialization, connection, and account checks were recorded as successful.
After main-window reload, codex-home became success / idle, workspace readiness became available, and the local request manager had zero incomplete requests.
Metadata collected during the successful reload showed local response delivery. This did NOT capture the original failed startup and therefore does not identify the first lost or unprocessed response.
Actual follow-up sends using both button click and Enter, with completed answers in an existing chat, were recorded in the earlier recovery tests. A later user confirmation also verified PC sending after diagnostic cleanup.

Direct recurrence and recovery (September 10)

Before recovery:

submitBlockReason = loading-local-config
localWorkspaceMaterialization = loading
isSubmitButtonLoading = false

The spinner boolean was false in this sample even though the configuration block was present; the spinner should not be treated as a necessary signature.

Only the actual main app window was reloaded. A changed renderer performance.timeOrigin verified that a real reload occurred. After initialization settled:

localWorkspaceMaterialization = available
submitBlockReason = empty-message

empty-message was expected because the composer was empty. The configuration block had cleared. The app main process stayed running. After temporary diagnostic connections were closed and their listening ports were confirmed absent, a follow-up test message arrived through the same existing chat and received an answer.

The 12-request count and fresh-request timings were not re-measured during this latest recurrence; they are earlier evidence, not new measurements.

Earlier code inspection and limits of the conclusion

The September 9 local investigation of the installed bundle recorded that the renderer-side local request manager registers requests in pendingRequests and resolves/removes them on fetch-response or cancellation. No intrinsic response deadline or missing-response retry was found in that inspected request path. This is a finding from the earlier bundle inspection; please verify it against the source for this build. It is not a claim that the entire application lacks timeout handling.

Together with the observed indefinite pending / fetching state, this suggests a failure mode in which an initialization read remains unresolved and keeps workspace materialization and sending blocked.

Hypothesis, not established root cause: a startup ordering, response-delivery, listener-readiness, or renderer completion problem leaves an early local request unresolved. The investigation did not trace the first failed request across every boundary. It cannot distinguish a response never emitted, a response not delivered, a listener not ready, or a response received but not used to settle the promise.

The earlier theory that the main-process send queue was currently congested was not supported by subsequent observations and was withdrawn. No causal evidence linked this failure to a specific skill, plugin, prompt-length warning, permission setting, conversation database corruption, or external-network outage.

What steps can reproduce the bug?

Observed user flow (not a deterministic minimal reproducer)

Launch the desktop app normally and open an existing chat.
Type a follow-up message and try the send button or Enter.
On affected launches, the send control appears unavailable or remains loading, with no explanatory error. The follow-up does not start a model run.
Navigate to another chat and return: the loading appearance may disappear, but the unsent draft remains. This does not restore sending.
A first message in a new chat may still work. During the earlier episode, mobile Remote could send while the PC composer could not, and the PC continued receiving conversation updates.
A normal app restart alone was followed by recurrence in earlier testing. Reloading the actual main app renderer after startup restored the existing-chat send path.

The frequency and precise timing conditions are unknown. This report does not claim every launch fails.

Recovery that worked and approaches that did not

Working recovery in the observed episodes:

Identify the running app and its actual main Electron window by type window and URL app://-/index.html.
Reload that main window with webContents.reload(), preserving the backend process where possible.
Wait for readiness to become available and the configuration block to disappear.
Close temporary diagnostics and verify a real follow-up send and completed answer in an existing chat.

An earlier successful full sequence was normal launch, wait for initial load, reload the main window once, verify sending, then close diagnostics without restarting again. The latest recurrence needed only the main-window reload.

This was a local diagnostic workaround, not a supported public repair API or a permanent fix. It did not patch the installed app, force readiness flags, delete conversations, reset login, disable security protections, or install a background monitor. Temporary diagnostics were loopback-only and closed afterward. The generic Ctrl+R shortcut was not established as equivalent; it may target the embedded browser instead of the app shell.

Earlier attempts that did not resolve the issue included re-approving Full access, opening another app window, switching Queue to Steer, disabling plugins and relaunching, and normal restart alone. Diagnostic changes were restored. An invasive startup debugger attachment also caused a separate hang during investigation; that diagnostic failure is not presented as the cause of the original send block.

What is the expected behavior?

Expected behavior

Local configuration and workspace initialization should complete or fail with a bounded, actionable error. Existing-chat sending should become available when its prerequisites are ready. A stalled read should offer a safe retry without losing drafts, clearing conversation history, changing permissions, or requiring a new chat.

Requested investigation and improvements

Please investigate the original failure, rather than only recommending repeated restarts:

Trace a local initialization read by request ID across request creation, main-process receipt, response emission, renderer receipt, and promise settlement, starting before initial renderer startup. Include lifecycle/disconnect events and request age, without logging user prompt contents or secret configuration values.
Review initialization/listener ordering and stale pending-request cleanup after renderer or bridge lifecycle changes. Ensure requests complete, cancel, or fail explicitly when their response cannot be delivered.
Add a bounded deadline and safe retry for idempotent local reads such as codex-home. Do not blindly retry model submissions or other side-effecting operations, and do not bypass workspace-readiness checks.
Surface a clear error and a user-accessible retry/reload action when local setup stalls. Preserve draft text and attachments, existing conversations, and running backend work.
Add regression coverage for delayed, missing, early, and out-of-order local responses; startup/restart and renderer reload; navigation between existing chats; new-chat first message versus follow-up; and mobile Remote sending while the desktop composer initializes.
Verify repeated ordinary launches and existing-chat follow-up sends without manual main-window reload or data resets. Confirm successful recovery also releases pending requests and does not create duplicate sends.

Additional information

Environment

Windows x64 desktop app, packaged installation.
Package version: 26.903.8094.0, confirmed again during the September 10 recurrence.
Internal app version: 26.903.61454; app-server version: 0.153.4, recorded during the September 9 investigation, not separately re-measured on September 10.
The earlier investigation recorded the updater displaying that the app was up to date. This is a historical observation, not a claim about the latest release at triage time.
Detailed diagnostics were collected on one affected PC. The user additionally reports recurrence of the same sending symptom on another PC; its exact environment and internal-state signature have not been independently verified.

Privacy

This report intentionally excludes names, contact details, account identifiers, machine/usernames, user-specific filesystem paths, private repository/project names, chat/session/request IDs, prompt contents, authentication data, screenshots, and raw logs. Only product versions, technical state fields, generalized reproduction steps, and sanitized diagnostic findings are included. No full chat export or diagnostic archive is attached.

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

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
Windows desktop app: second/follow-up message hangs indefinitely in Work and Codex after Sep 5 update #43366

Powered by Codex Action

Additional reproduction on Windows x64, September 11, 2026, with installed package OpenAI.Codex 26.903.9818.0.

The user-visible failure matches this report: a follow-up message remains in the composer with a spinning Send control. It does not become a normal submitted message.

Observed through local runtime diagnostics after a Desktop-only restart:

submitBlockReason = loading-local-config
isResponseInProgress = false
isResumePending = false
Both ['vscode', 'codex-home'] and its local-host variant remained pending / fetching.
In this sample, localWorkspaceMaterialization = available despite the configuration submission block. Workspace availability alone therefore did not establish that sending was ready.

Recovery findings and limits:

Cancelling and invalidating the two home queries returned the actual directory metadata and changed both to success / idle. This alone did not clear the submission block on this build.
Retrying additional stalled local state and permission/readiness metadata reads cleared submitBlockReason to null. This was a batch of read-only retries; the individual decisive dependency was not isolated. No permission settings or readiness checks were changed or bypassed.
The subsequent user test still reported failure. Inspection showed that the guarded process had exited and the app had been relaunched normally without the temporary workaround. This does not demonstrate reliable follow-up recovery.
A later guarded launch reproduced the stall again. The bounded read-retry guard recorded one recovery; both home queries became success / idle, and the composer reported empty-message, consistent with an empty composer. Successful first-message plus two-follow-up replies after that recovery remain unverified.

A normal process restart did not reliably prevent recurrence. This should not be treated as fixed by restarting, reinstalling, or clearing a readiness flag. The underlying reason these reads fail to settle remains unconfirmed.

Please investigate the local request/response completion lifecycle and add bounded failure handling plus a supported retry action that preserves drafts and existing conversations. Regression coverage should verify actual repeated follow-up submission after ordinary launches, not only directory-query success or workspace availability.

No raw logs, screenshots, account identifiers, chat contents, session IDs, private paths, or configuration values are attached.

Still experiencing the same user-visible symptom on Windows as of September 12, 2026.

Environment checked for this report:

Installed package: OpenAI.Codex 26.908.4834.0.
OS: Microsoft Windows NT 10.0.19045.0.

Reproduction:

Start a new chat and send the first message.
Wait for the reply to finish.
Try to send a follow-up in that chat.
Send remains greyed out with a spinner, preventing the follow-up from being submitted.

Earlier troubleshooting recorded that the test task had finished and 99% of the weekly allowance remained at the time of that check. Restarting the app multiple times did not resolve the problem. The earlier log review also reported conversation-state errors across restarts; exact error strings are not included here.

Expected: once the reply finishes, the composer should become ready and allow subsequent messages.

This is a report of matching visible symptoms. The specific loading-local-config / codex-home state described above has not been independently established on this PC, and the root cause remains unconfirmed. The issue is still unresolved here.

Additional verified recovery on Windows package 26.908.4834.0, September 13, 2026 (UTC+8). The loading-local-config / pending codex-home signature was directly established on this PC, and recovery was verified through the normal desktop composer. This is additional runtime evidence for the matching symptoms discussed here.

Observed before recovery

The actual main Electron webContents was identified by type window and exact URL app://-/index.html, excluding the avatar overlay, detached window and embedded browser/webviews. In an existing conversation whose previous reply had finished:

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

["vscode", "codex-home", "{\"hostId\":\"local\"}"]
  status=pending, fetchStatus=fetching, no data, no error
["vscode", "codex-home"]
  status=pending, fetchStatus=fetching, no data, no error

markedStreaming=true was not used as evidence that a turn was still running.

Recovery performed, without restarting or reloading

Enabled a temporary Node inspector on the already-running desktop main process, listening only on 127.0.0.1. No startup debugger pause or application relaunch was used. On this installation, a local Node process could activate the existing main process's inspector with process._debugProcess(actualDesktopMainPid); this is an internal, unsupported diagnostic mechanism, not a public repair API. The PID was identified from the installed desktop executable, not from a codex.exe CLI/app-server process.
Enumerated Electron webContents through that diagnostic connection and selected the exact main-window target above. Inspected its existing React/TanStack Query client and composer props. The renderer query client was found by inspecting the React provider value exposing getQueryCache and cancelQueries; those private implementation details are build-specific.
Cancelled the two stuck read-only codex-home queries first, then refetched those exact queries. No readiness flags, cached results or permission settings were manually changed.

The essential operation, once the actual main renderer's queryClient has been obtained, is:

const targets = queryClient.getQueryCache().getAll().filter(q =>
  q.queryKey[0] === "vscode" &&
  q.queryKey[1] === "codex-home" &&
  q.state.status === "pending" &&
  q.state.fetchStatus === "fetching"
);

// Capture the exact query identities before cancellation changes their state.
const hashes = new Set(targets.map(q => q.queryHash));
const filter = { predicate: q => hashes.has(q.queryHash) };

await queryClient.cancelQueries(filter);
await queryClient.refetchQueries(filter);

This code requires the existing app query client; queryClient is not a guaranteed console global. In this recovery, the target count was checked to be exactly two before proceeding. Do not apply this indiscriminately to submissions or other operations with side effects.

Both queries returned actual directory metadata and became success / idle. Workspace materialization became available. The submit block became null with a draft, and empty-message when the composer was empty. The renderer's performance.timeOrigin stayed unchanged: no main-window reload or Ctrl+R was involved.

Actual follow-up validation

In the same pre-existing conversation, after its earlier reply had completed:

Typed a short test into the normal composer and clicked Send. A complete reply was displayed.
Closed the temporary inspector and confirmed its listening port was gone. After the first test reply completed, typed another test into the same composer and pressed Enter. A second complete reply was displayed.

The two test turns completed at 01:28:39 and 01:29:41 UTC+8. Desktop main-process and app-server PIDs and start times were unchanged. The pre-existing unsent draft was preserved and restored after testing. No send_message_to_thread or equivalent tool was used to submit either test. Backend completion status was used only as a cross-check of the visible desktop replies.

Limits

This is a verified recovery for this running session, not a permanent fix. The original startup request/response failure boundary remains untraced; another ordinary launch may reproduce the problem. No restart was performed after recovery just to test recurrence.
Eight other local initialization queries still showed pending / fetching: locale, three global-state reads, inbox list, automation list, shortcut state, and Chronicle permission metadata. They were not retried in this recovery and did not prevent the two successful composer sends. This does not establish that all initialization problems are resolved.
Unlike the earlier report where additional metadata retries were necessary, the two home-query retries alone cleared the sending gate in this particular occurrence. This difference should not be generalized to all builds or episodes.
No history deletion, .codex reset, session-database edit, cache clearing, permission/security change, installed-bundle modification, readiness bypass or persistent recovery guard was used. Temporary diagnostics were closed.

This corroborates the cancel-then-refetch finding in #45069, with explicit repeated desktop-composer validation. A supported bounded timeout/retry path for lost initialization reads is still needed.

Thanks for documenting this workaround. It restored follow-up messaging on my Windows Codex Desktop, version 26.908.70816 (package 26.908.9136.0).

New chats could send the first message, but follow-ups were blocked. PC/app restarts and model changes did not help. codex resume --all could still send to the same sessions, with replies syncing back to Desktop.

Diagnostics confirmed two local codex-home queries stuck in pending / fetching, with submitBlockReason = loading-local-config. Calling webContents.reload() from the main process on the actual main window (app://-/index.html, type window) changed both queries to success / idle and workspace readiness to available. I then confirmed that sending worked in another existing conversation. An earlier CDP Page.reload attempt had not resolved the issue.

No session or account data was deleted. The existing main and backend processes stayed running, and temporary diagnostic ports were closed afterward. I have not tested whether the recovery survives a full app restart.

I’m not a developer; I used Astra Light in Codex Desktop to investigate the issue and apply the workaround described here, then personally confirmed that sending worked again.

Update — restart test: After posting this, I restarted the app to check whether the recovery would persist. It did not: the local Work conversations I tried were blocked again, while my cloud conversations still worked.

I continued the troubleshooting through Codex in the browser. Diagnostics on my PC again confirmed two local codex-home queries stuck in pending / fetching and submitBlockReason = loading-local-config. Calling webContents.reload() from the desktop main process restored both queries to success / idle and cleared the submission block again.

I then personally sent a follow-up in Desktop, received a reply, and confirmed that the existing conversation content was still accessible. No session data was deleted, and the temporary diagnostic port was closed afterward.

This confirms a second successful recovery on my machine, but also that the workaround did not survive an app restart in this test.

September 16 update: targeted recovery on 26.908.9136.0, plus startup response-loss evidence

Following up on my earlier recovery report. This problem still recurs on Windows package 26.908.9136.0, with app-server 0.154.0-alpha.6.2. It has been requiring roughly 7–8 manual recoveries per day on this installation.

The targeted workaround again cleared the configuration blocker without resetting data or changing permissions. It is not a permanent fix.

Identify this specific failure first

Two repeated runtime samples showed:

submitBlockReason = loading-local-config
localWorkspaceMaterialization = loading

["vscode","codex-home","{\"hostId\":\"local\"}"]
["vscode","codex-home"]

Both: status=pending, fetchStatus=fetching, dataUpdatedAt=0, error=null

Some other configuration/permission queries had completed. Fourteen local bridge requests remained pending. While the original requests were still stuck, five fresh read-only codex-home requests all returned 200 in approximately 0.7–3.6 ms, without settling the original fourteen requests. These are local bridge timings, not internet latency. The inspected main-process ChunkedMessageSender had no queued targets.

Recovery: cancel the exact stuck reads, then fetch real configuration again

The key is cancel first, then refetch. Invalidating an already-fetching query alone can leave it waiting for the same unresolved request.

For developers diagnosing this build, the following is the bounded form of the operation. queryClient must be the existing main renderer's actual TanStack QueryClient, not a newly created client or an assumed console global. Inspect the actual visible Electron main window (type=window, exact URL app://-/index.html), excluding detached windows, avatar overlays and embedded webviews. The private React/provider access used to obtain this client is build-specific; this is an unsupported diagnostic workaround, not a public repair API.

async function recoverStuckHomeReads(queryClient) {
  const keys = [
    ["vscode", "codex-home", JSON.stringify({ hostId: "local" })],
    ["vscode", "codex-home"],
  ];
  const lookup = queryKey => queryClient.getQueryCache().find({
    queryKey, exact: true,
  });
  const bothStuck = () => keys.every(key => {
    const q = lookup(key);
    return q?.state.status === "pending" &&
      q.state.fetchStatus === "fetching" && q.state.dataUpdatedAt === 0;
  });
  if (!bothStuck()) throw new Error("Expected failure signature absent");
  await new Promise(resolve => setTimeout(resolve, 5000));
  if (!bothStuck()) throw new Error("State changed; stop and re-inspect");

  const cancel = async () => {
    for (const queryKey of keys) {
      await queryClient.cancelQueries({ queryKey, exact: true });
    }
  };
  await cancel();
  let timer;
  try {
    await Promise.race([
      Promise.all(keys.map(queryKey => queryClient.refetchQueries(
        { queryKey, exact: true, type: "all" }, { throwOnError: true }
      ))),
      new Promise((_, reject) => {
        timer = setTimeout(() => reject(new Error("Read timed out")), 8000);
      }),
    ]);
  } catch (error) {
    await cancel();
    throw error;
  } finally {
    clearTimeout(timer);
  }
  return keys.map(key => {
    const s = lookup(key).state;
    return {
      key, status: s.status, fetchStatus: s.fetchStatus,
      dataUpdatedAt: s.dataUpdatedAt,
      hasRealPath: typeof s.data?.codexHome === "string" &&
        s.data.codexHome.length > 0,
    };
  });
}

After the actual recovery, both reads returned real directory metadata and became success/idle; workspace materialization became available. The remaining submit reason was empty-message, appropriate for the empty composer. If another submit blocker remains, inspect it separately; do not broaden the retry to submissions or arbitrary operations. Do not use setQueryData, force readiness flags, or bypass permission/workspace checks.

Any temporary inspector should be loopback-only, attached to the identified desktop main process, and closed afterward with the listener's disappearance verified. The main executable can be named ChatGPT.exe inside the OpenAI.Codex package; codex.exe may instead be the backend. Do not choose a process solely by CPU/memory usage. Details of this diagnostic setup and cleanup are in the earlier linked comment.

New evidence useful for a permanent fix

With request-ID-only instrumentation installed before a controlled main-renderer reload, one run recorded 66 outgoing local requests, 66 main-process response-send calls, but 65 renderer response observations. The missing response was for set-remote-wsl-connections-enabled, had status 200, and its request remained pending. The main instrumentation ran immediately before delegating to the original webContents.send: this establishes an attempted send, not acknowledged delivery. Two subsequent reloads had no pending bridge requests.

This captures a related startup response-completion failure, but does not prove the original codex-home requests were lost at exactly the same boundary, or pinpoint the Electron/preload implementation responsible.

Inspection of this installed build also found:

The renderer's local sendRequest path registers a pending request but has no intrinsic response deadline; absent a response or cancellation, it can remain unresolved indefinitely.
The bridge's asynchronous sendMessageFromView(...).catch(...) logs failure without propagating it to the pending-request owner. This is an additional potential indefinite-pending path; an actual send rejection was not captured in this incident.

Please prioritize end-to-end completion/receipt handling, propagation of asynchronous send failures, bounded deadlines and limited retries for explicitly idempotent initialization reads, and a visible Retry action. Navigation/reconnect should settle or cancel requests from the old lifecycle. Do not automatically replay user message submissions or configuration mutations.

Validation limits: the runtime configuration blocker was cleared in this September 16 run. Two normal-composer follow-up sends were verified in the earlier September 13 report, but were not repeated as a controlled end-to-end test in this run. Multiday nonrecurrence remains unverified. No session databases, history, permissions or installed app files were modified; no persistent recovery agent was installed, and the temporary Node inspector was closed. No raw logs, screenshots, private paths, prompt contents or account/session identifiers are attached.

Additional reproduction from another Windows user, September 17, 2026 (UTC+8).

After fully quitting Codex from the system tray and reopening it, the first message in both existing and new chats fails to submit. The Send arrow becomes dim blue/gray and then spins indefinitely. No answer or new turn appears. Signing out of the ChatGPT account and signing back in restores sending for that app session. The failure recurs after the next full quit and cold launch. Restarting the app alone does not recover it.

Deleting the user's .codex directory once restored sending temporarily, but the failure returned after the next shutdown/restart. Other local state/config resets did not establish a lasting fix and were rolled back.

Diagnostics during an affected launch:

The account is detected as authenticated.
The local backend is connected.
The authenticated model-list request returns HTTP 200.
Clicking Send does not produce a turn/start request in the app logs.
After sign-out/sign-in, turn/start appears and messages work.
No pre-logout HTTP 401 was observed.

This suggests the failure occurs before turn submission in the Windows desktop UI/startup state, but the root cause is not proven. Please investigate why cold launch leaves message submission blocked, why sign-out/sign-in reinitializes it, and whether this is related to the pending local-config / codex-home state reported here. A supported recovery path that preserves drafts and chats would help until a permanent fix ships.

This report intentionally excludes account identifiers, local usernames, paths, private chat contents, raw logs, and authentication material.

signing in and out resolves it

…

On Thu, Sep 17, 2026 at 3:58 AM qin532 ***@***.***> wrote: *qin532* left a comment (openai/codex#44342) <#44342 (comment)> Additional reproduction from another Windows user, September 17, 2026 (UTC+8). After fully quitting Codex from the system tray and reopening it, the *first message* in both existing and new chats fails to submit. The Send arrow becomes dim blue/gray and then spins indefinitely. No answer or new turn appears. Signing out of the ChatGPT account and signing back in restores sending for that app session. The failure recurs after the next full quit and cold launch. Restarting the app alone does not recover it. Deleting the user's .codex directory once restored sending temporarily, but the failure returned after the next shutdown/restart. Other local state/config resets did not establish a lasting fix and were rolled back. Diagnostics during an affected launch: - The account is detected as authenticated. - The local backend is connected. - The authenticated model-list request returns HTTP 200. - Clicking Send does *not* produce a turn/start request in the app logs. - After sign-out/sign-in, turn/start appears and messages work. - No pre-logout HTTP 401 was observed. This suggests the failure occurs before turn submission in the Windows desktop UI/startup state, but the root cause is not proven. Please investigate why cold launch leaves message submission blocked, why sign-out/sign-in reinitializes it, and whether this is related to the pending local-config / codex-home state reported here. A supported recovery path that preserves drafts and chats would help until a permanent fix ships. This report intentionally excludes account identifiers, local usernames, paths, private chat contents, raw logs, and authentication material. — Reply to this email directly, view it on GitHub <#44342?email_source=notifications&email_token=BVZOVNYYJF3EOFRETF2UUH35PNHOPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZQG43TQOBYGU32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5707788857>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVZOVN6VSGPKMTJBJ4OQS5L5PNHOPAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKNBQGYYDEMBYG432C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BVZOVN5W4BLEACDLX57KD6T5PNHOPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZQG43TQOBYGU32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BVZOVN224B5XIDXER4MZN535PNHOPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZQG43TQOBYGU32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

September 18, 2026: reproduced on 26.915.3509.0; fast model/list does not clear the local-config blocker

Adding measurements from another Windows installation. Sending was restored, but a full exit/relaunch reproduced the failure; this is not a permanent fix.

Environment: Windows package 26.915.3509.0, internal version 26.915.31029, build 9771, bundled CLI 0.155.0-alpha.9.

Isolation of model-list latency: Initially, model/list took approximately 5009–5018 ms. After configuring a validated local model catalog through model_catalog_json, observed desktop calls took 0–12 ms. The local-config send blocker still occurred. This isolates the model-list timeout as an insufficient explanation for the remaining failure, not a claim that all network problems are excluded.

Observed blocked state in the actual main renderer:

isResponseInProgress = false
isResumePending = false
submitBlockReason = loading-local-config
localWorkspaceMaterialization = loading
codex-home queries (default/local host) = pending / fetching
managed-worktree-state = codex-home-loading / pending / idle

One snapshot contained 13 outstanding local bridge requests.
A newly issued read-only codex-home request returned the real directory in approximately 1.1 ms while the original queries remained pending.
The existing test conversation had successfully completed thread/resume; its previous turn was completed.
Clicking Send while blocked did not produce turn/start. The submission was blocked before model execution.

Recovery and recurrence:

Reloading only the main app://-/index.html renderer, with the main process and backend kept alive, changed codex-home to success / idle and workspace readiness to available / success / idle.
A follow-up sent through the normal composer in the same test conversation produced turn/start and the expected reply. This was a UI-path test, not a direct backend submission.
Fully exiting and relaunching the desktop app reproduced the pending local-config state.
A second main-renderer reload restored sending; a second composer follow-up received its expected reply.
Returning to the original conversation showed workspace available, no submit block reason, and an enabled Send button. Its pre-existing draft was preserved and was not submitted.

Temporary loopback diagnostic listeners were closed afterward and verified absent. No installed application bundle was modified, conversation history deleted, or security permissions relaxed. The model-catalog configuration change described above remained in place.

Proven failure chain versus unresolved trigger:

The observed chain is outstanding local requests → pending home queries → workspace preparation never becoming ready → submission blocked. Read-only inspection of the installed local-request path found a pending-request map completed by a response or cancellation, without an intrinsic response deadline in that path. This permits an uncompleted initialization request to leave the UI blocked indefinitely.

The first failed request was not traced end-to-end across renderer dispatch, main-process receipt, response dispatch, renderer receipt, and promise settlement. The initial missing-completion boundary and its trigger remain unproven. A startup timing or response-delivery problem is a hypothesis, not a confirmed root trigger.

Could maintainers confirm whether this newer-build reproduction is covered by an upcoming fix, and which additional sanitized instrumentation would help identify that first missing completion? A durable fix needs explicit completion/failure handling for initialization reads, bounded waiting, safe cancellation, and a visible retry path that preserves drafts. Any automatic retries should be limited to suitable idempotent reads, not blind retries of turn/start or other side-effecting operations.

Our proposed acceptance check is at least three ordinary cold launches with no diagnostic connection or manual reload, each completing both a new-conversation send and an existing-conversation follow-up. This build did not meet that criterion.

This comment contains only a sanitized diagnostic summary, with no raw logs, screenshots, account data, local filesystem paths, conversation identifiers, or user prompts.

Root cause narrowed down, plus a workaround that recovers without reloading the window.

Instrumented all three hops on 26.915.4065.0 / app 26.915.31945 (Windows Store package), with the same requestId traced through each hop:

renderer → main: the vscode://codex/codex-home request arrives ([electron-fetch-handler] codex-home request in the main-process log);
main → renderer: readCodexHomePaths is effectively synchronous for the local host and the fetch-response is handed to webContents.send within ~1 ms;
renderer: the window message event for that requestId never fires during the first seconds after startup, so the React Query entries ["vscode","codex-home"] and ["vscode","codex-home",{"hostId":"local"}] stay pending/fetching with dataUpdatedAt=0 forever. The same happens to ~9 sibling startup queries (get-global-state ×3, locale-info, inbox-items, list-automations, codex-command-keymap-state, paths-exist, global-dictation-hotkey-state).

Once the app is up, cancelling and refetching those same queries completes in ~3 ms end-to-end (main received → main replied → renderer received, all confirmed), the workspace flips to available, submitBlockReason goes from loading-local-config to empty-message, and Send is enabled — no window reload needed. So the responses to the very first batch of local requests are dropped somewhere on the main→renderer delivery path during startup, and nothing retries them.

Workaround (MIT, Windows, Node 22+): https://github.com/GoMaaars/codex-desktop-send-button-fix — attaches to the main process over the loopback inspector, asks the renderer to re-issue every stuck vscode/* query, and closes the inspector. Optional watcher does this automatically ~45 s after each app start. Only public Electron/React Query APIs plus process._debugProcess and ipcMain._invokeHandlers; no build hashes, so it survives updates.

Suggested fix on the app side: give the local fetch bridge a deadline and a retry for the startup batch, or have the renderer re-issue vscode/* queries whose responses did not arrive within N seconds of app routes mounted.

becoming a joke now consrtantly signing off and back in to have a convo

Adding a newer reproduction on Windows 11 x64 (2026-09-21), app 26.915.31945 build 9922, package 26.915.4065.0, backend 0.155.0-alpha.9.2.

The same follow-up send block still occurs after a full uninstall/reinstall of the current package. On affected launches, submitBlockReason=loading-local-config and localWorkspaceMaterialization=loading while isResponseInProgress=false. Startup vscode://codex/* reads such as codex-home, paths-exist, locale-info, get-global-state, inbox-items, list-automations, codex-command-keymap-state, and global-dictation-hotkey-state remain pending/fetching. New requests over the same bridge can still return 200.

Refetching only the genuinely pending/fetching read queries changes workspace materialization to available and clears the submission block. Two real UI sends then succeed. After a normal restart, the issue can recur. This is a diagnostic workaround only; no app files or permissions were changed.

Please consider this a current-version reproduction of #44342 and investigate the startup response/lifecycle path, with bounded retry/error recovery that preserves drafts.

how is this still not fixed to reply to a convo i have to resrtat sign out and back in every time, remote connection is broken since this bug its becoming a joke i have the lateset version installed this is getting tiring

September 23 follow-up: startup reads still stall on Windows package 26.917.6896.0

The user reported the same desktop follow-up sending symptom after updating to the installed Windows package OpenAI.Codex 26.917.6896.0 (Windows package status: Ok). This is a recurrence report, not a claim that every launch fails.

During a subsequent controlled recovery launch, the actual main renderer had 11 vscode://codex/* initialization reads in pending / fetching, including codex-home (two entries), paths-exist, locale-info, get-global-state, inbox-items, list-automations, codex-command-keymap-state, and global-dictation-hotkey-state. Only those observed stuck read queries were cancelled and refetched. All 11 returned success with real responses. The inspected workspace materialization then reported available; no tracked read query remained pending / fetching. Diagnostic sessions were detached. No installed app files, account state, permissions, or conversation data were changed.

Validation limit: The private composer-state inspection used in the previous build did not resolve on this build, and this recovery log alone does not establish that two follow-up messages were submitted through the normal desktop composer. It is a current-version observation of the same startup-read stall and a successful read-only retry, not proof of a permanent or fully validated UI repair. The first missing-response boundary remains unconfirmed.

Later user confirmation: The user subsequently tested desktop sending and reported that it works again. This is user-confirmed functional recovery after the workaround; it does not establish that ordinary startup without recovery now works or that future launches will stay healthy.

Please keep this version in the investigation of initial local-request completion, bounded failure/retry for idempotent startup reads, and a visible recovery path that preserves drafts. No raw logs, personal paths, chat identifiers, prompt text, account data, or secrets are included here.

Additional September 23 reproduction: exact composer gate captured, recovery limited to two reads

Adding a separately observed recurrence on Windows x64, installed package 26.917.6896.0. The user reports recurrent sending failures since approximately September 10 despite several application updates. This is not a claim that every launch fails or that every historical episode shares the same cause.

In the afternoon recurrence, the app was running in a different main process from the morning observation. The main renderer showed:

State	Before targeted retry	After targeted retry
`["vscode","codex-home"]`	pending / fetching; no data, no error	success / idle; data present
`["vscode","codex-home","{\"hostId\":\"local\"}"]`	pending / fetching; no data, no error	success / idle; data present
`localWorkspaceMaterialization`	loading	available
Composer `submitBlockReason`	loading-local-config	empty-message (empty composer)

This recovery retried only those two read-only queries. It did not retry all pending reads, reload/restart the application, change permissions, alter installed application files, clear profile/session data, or force readiness flags. Other pending reads were left untouched. The temporary local diagnostic interface was closed afterward.

Functional validation: The user then tried the normal desktop send control and explicitly confirmed sending worked. This confirms recovery of the observed episode; repeated successful launches or a permanent fix have not been established.

Code-inspection lead, not a proven initial root cause

Read-only inspection of the installed package indicates:

The renderer's local vscode://codex/ request path creates a pending promise settled by a response or external cancellation. That function itself has no timeout timer.
The workspace readiness path remains loading while the home-path query has neither data nor an error.
The main-process home-path handler awaits platform/path and workspace-root operations. A rejection handler alone would not settle a dependency that never completes.

This identifies a mechanism by which an unfinished local read can keep the composer blocked, but does not locate the first missing-completion boundary. Initial request delivery, backend initialization/dependencies, response delivery, and promise settlement still need correlated tracing; timeout behavior in other layers has not been ruled out.

Please investigate that initial boundary and add bounded failure/cancellation plus limited retries for these idempotent reads, with a visible recovery action that preserves drafts. Please include regression coverage for ordinary app restart, delayed/missing local responses, existing-thread navigation, and two successive manual follow-ups. Model submissions and other side-effecting operations should not be automatically replayed.

This comment contains sanitized technical findings only; no private project names, personal filesystem paths, chat/account identifiers, prompt contents, raw logs, or screenshots are included.

September 23: reproduced on Windows package 26.917.8451.0, recovery verified in the UI, and a diagnostic-reattachment crash

Hi OpenAI team,

First, thank you for building ChatGPT and Codex. I love the product and appreciate the work that goes into it. I am reporting this because I want to keep using it reliably.

This problem has cost me hours and a substantial amount of Codex usage just troubleshooting how to use Codex Desktop itself, rather than doing my actual work. I have not measured an exact token total or monetary cost, so I do not want to invent one. Repeatedly losing the ability to send a follow-up is a serious interruption. I eventually needed a separate terminal conversation as a working contact route while Desktop was blocked.

With my authorization, Codex helped prepare this sanitized report from local observations. This appears to match the startup-read failure already reported here; the original missing-completion boundary is still unproven.

Environment and reproduction

Windows x64, OS build 10.0.26200.
Installed Windows package OpenAI.Codex 26.917.8451.0.
The app's update check reported it was current during this investigation.
A first message could work, but follow-ups remained in the composer with a spinning send control and no new model turn.
The symptom occurred with and without a project. Ordinary restarts, a backed-up temporary Chromium cache reset, and switching the follow-up mode did not resolve it.
The separate terminal session continued handling consecutive messages. This established an alternative contact route, not a repaired Desktop.

What actually recovered the observed episodes

In the actual main app renderer (type=window, exact URL app://-/index.html), these two queries remained stuck:

["vscode", "codex-home"]
["vscode", "codex-home", JSON.stringify({ hostId: "local" })]

Both had status=pending, fetchStatus=fetching, dataUpdatedAt=0, and no directory response. They were still stuck after a second check five seconds later.

Only those two exact read queries were cancelled and refetched through the existing QueryClient. Both returned real directory responses and became success/idle. No readiness flags were forced, permissions bypassed, installed app files patched, or model submissions replayed. Conversation history and sign-in were preserved.

Functional validation went beyond query-state inspection:

Two follow-ups in an existing chat received visible replies after recovery.
After a normal full app restart, the same read stall recurred. A local startup workaround recovered it, and two follow-ups in an existing chat received replies.
After another normal restart and recovery, a new test chat's first message and its follow-up received replies.
After a later normal launch with automatic recovery disabled, the send block returned again. A controlled first diagnostic connection to that process recovered exactly the same two reads. The app then sent my already-waiting message and started responding, without a separate resend by the diagnostic script.
Two further messages submitted through the normal Desktop composer received visible replies at 10:35:44 and 10:36:12 UTC on September 23. The visible results were cross-checked against local completion records.

These are observations from specific tests, not a guarantee that every launch or configuration behaves identically.

Separate diagnostic crash: please do not treat this workaround as a general repair recommendation

A later second Node-inspector connection to an already-diagnosed app process coincided with a confirmed browser-process crash. I did not close the app. Crashpad recorded it at 10:22:50 UTC, immediately after the connection attempt: exception 0x80000003 in chrome.dll, module offset 0xB5C5A42, ptype=browser.

Repeated attachment is a suspected trigger, not a proven cause; a symbolized stack is not available. This diagnostic incident is separate from the original send block, which also occurred without any diagnostic attachment.

Automatic recovery was therefore disabled. The local diagnostic tool now persistently blocks a second attachment to the same process/start time, even after a failed attempt; that refusal was tested without opening another connection. This limits the observed risk path but does not establish that all first attachments are safe. Only passive process/crash-file metadata monitoring remains enabled. The dump is preserved locally and is not attached because it may contain private memory.

What would help permanently

Please investigate the initial read across request creation, main-process receipt, dependency completion, response delivery, and renderer promise settlement. Our observations do not prove where the first completion is lost.

A supported fix should provide bounded failure/cancellation and limited retries for these explicitly idempotent startup reads, plus an actionable retry option that preserves drafts and conversations. It should never blindly replay model submissions or other writes. Please verify ordinary launches and repeated real follow-ups with all diagnostic workarounds disabled, including existing-chat navigation and new-chat first-message/follow-up behavior.

The app is usable again after targeted recovery, but the underlying product bug is not permanently fixed. Users should not need hours of paid-product troubleshooting or internal debugger work just to continue a conversation.

Thank you again for the excellent product and for looking into this. I hope these verified findings help both your team and the other people affected.

No private conversation contents, project names, personal paths, account/session identifiers, credentials, screenshots, raw logs, or memory dumps are included.

September 24 follow-up: exact gate recovered in place on 26.917.8451.0

I reproduced this again on Windows x64 with the installed package OpenAI.Codex 26.917.8451.0 (internal app version 26.917.62051; the built-in update check reported up to date). Remote could continue the conversation while the Windows Desktop composer could not submit a follow-up.

In the already-running main renderer, before intervention:

submitBlockReason=loading-local-config
localWorkspaceMaterialization=loading
The two vscode/codex-home queries, default and hostId=local, were both pending/fetching, with no data and no error.

I cancelled and refetched only those two read-only queries through the existing QueryClient. Both became success/idle with data. A separate inspection then found localWorkspaceMaterialization=available and the composer block reason empty-message while its input was empty. The user subsequently confirmed that normal sending in the Windows app works again. This is user-confirmed functional recovery of this episode; I did not independently count two successive Desktop sends in this latest run.

The app was not restarted, its installed files/profile/conversations were not changed, and no model submission was replayed by the recovery. The temporary loopback diagnostic port was closed and verified closed. This does not establish a permanent fix: an ordinary restart after this recovery and future package/Windows updates have not been validated here. Previous launches have reproduced the stall.

The local shortcut was changed to run an exact-signature-guarded in-place recovery rather than the older restart path that failed with spawn EPERM; the shortcut's already-ready/no-op path was exercised. Its cold-start path remains untested. This uses unsupported Electron/Node inspector access and should not be treated as a recommended product fix, especially given the separate reattachment-crash report above.

Please fix the original request-completion failure in the app, add a bounded error/retry for these idempotent startup reads while preserving drafts, and cover ordinary restart/update plus normal existing-chat follow-up sending in regression tests. No private paths, thread/account identifiers, prompt contents, raw logs, or credentials are included here.

Reproduced on Windows x64 with Codex Desktop package 26.924.1866.0 after updating on September 26, 2026.

Actual behavior

The app window appears but remains indefinitely on the loading spinner.
Logs show that the local app-server initialized successfully and the ChatGPT account lookup succeeded.
Startup then emits codex-home request hostId=undefined, with no completion afterward.
app_start later fails with reason=timeout after approximately 121–130 seconds.
Codex Beta package 26.727.4816.0 works on the same machine, account, and network.

Troubleshooting attempted without recovery

Normal restart and a full shutdown/restart of Stable, Beta, and the shared Codex backend
Rebuilding only Chromium caches (Cache, Code Cache, GPUCache, and shader caches)
Launching with an isolated fresh user-data directory
Re-registering the current AppX package; package status remains Ok

Conversation and login data were preserved throughout these tests.

This appears to be the same pending codex-home / local-initialization failure, but in 26.924.1866.0 it can block application startup entirely. Please add a bounded timeout/retry and a visible reload or recovery action.

Additional evidence: local renderer fetch requests can remain pending after native bridge invocation fails. This is a reproducible error-propagation defect in both installed Windows package 26.930.7945.0 (client 26.930.61225 / build 13232) and downloaded package 26.1002.7124.0 (client 26.1002.52244 / build 13536).

We executed the exact extracted production sendRequest/onFetchResponse methods, bridge postMessage function and complete message-bus class in an isolated Node VM, mocking only the native IPC endpoint and required browser/logging primitives. No live debugger, installed-package modification or profile reset was used.

Control: a matching successful fetch-response resolves the Promise and leaves pendingRequests.size=0.
Failure: make electronBridge.sendMessageFromView reject. The bridge logs its warning, but the original local fetch Promise is neither rejected nor removed from pendingRequests. It remains pending after the bounded 500 ms observation. Source inspection independently shows no general timeout in this path. Explicit caller abort rejects the Promise and clears the pending entry. Both scenarios behave identically in both packages.

This does not establish the initial trigger of the historical user incidents. Historical snapshots showed codex-home pending/fetching and loading-local-config blocking follow-up sends; other original renderer requests also remained pending while main active handlers and outbound queues were empty. Fresh local reads could succeed in the same document. The original request-ID lifecycle was not captured, and no matching native-invoke failure was retained for those incidents.

A separate historical Windows 10 startup timed out at 121647.8 ms after successful host/settings/account initialization, with no shell/home/sidebar paint marks. Its exact blocked renderer dependency was not captured; we are not asserting that it shares the same trigger.

Please propagate native-send failures to the associated fetch Promise, settle pending requests on transport/document teardown, and add bounded recovery for safe startup reads. A supported diagnostic trace covering requestId across renderer send, main receive/reply, preload receipt and renderer settle would identify the missing historical boundary. Please identify a release containing the applicable fix rather than treating a successful restart as proof of resolution.

Source bundle SHA256:
26.930.7945.0: b9468897f9c8a96395322ae4b2a2446914f50670403466c0c8889a40eb23f3cf
26.1002.7124.0: 35b467c3a05695ec354eb1d0bb4572ad7e9d1480decc1cf0fae3d16b50aa5bd8

Related reports, independently reported by their authors:
#44342
#45069
#48466

Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur #44342

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?

Summary and impact

Additional history reported by the user (September 10 update)

Actual state and evidence

Earlier diagnostics (September 9)

Direct recurrence and recovery (September 10)

Earlier code inspection and limits of the conclusion

What steps can reproduce the bug?

Observed user flow (not a deterministic minimal reproducer)

Recovery that worked and approaches that did not

What is the expected behavior?

Expected behavior

Requested investigation and improvements

Additional information

Environment

Privacy

Activity

github-actions commented on Sep 10, 2026

nondualistcoder commented on Sep 11, 2026

seanmartina commented on Sep 12, 2026

lishuoipad commented on Sep 12, 2026

Observed before recovery

Recovery performed, without restarting or reloading

Actual follow-up validation

Limits

SovereignAxis commented on Sep 15, 2026

lishuoipad commented on Sep 16, 2026

September 16 update: targeted recovery on 26.908.9136.0, plus startup response-loss evidence

Identify this specific failure first

Recovery: cancel the exact stuck reads, then fetch real configuration again

New evidence useful for a permanent fix

qin532 commented on Sep 17, 2026

seanmartina commented on Sep 17, 2026

yiliwulu1999yunnan-boop commented on Sep 18, 2026

September 18, 2026: reproduced on 26.915.3509.0; fast model/list does not clear the local-config blocker

GoMaaars commented on Sep 20, 2026

seanmartina commented on Sep 20, 2026

TomassonJW commented on Sep 21, 2026

seanmartina commented on Sep 22, 2026

seanmartina commented on Sep 22, 2026

TomassonJW commented on Sep 23, 2026

September 23 follow-up: startup reads still stall on Windows package 26.917.6896.0

Jiaxu666-dev commented on Sep 23, 2026

Additional September 23 reproduction: exact composer gate captured, recovery limited to two reads

Code-inspection lead, not a proven initial root cause

PostmanTeddy commented on Sep 23, 2026

September 23: reproduced on Windows package 26.917.8451.0, recovery verified in the UI, and a diagnostic-reattachment crash

Environment and reproduction

What actually recovered the observed episodes

Separate diagnostic crash: please do not treat this workaround as a general repair recommendation

What would help permanently

TomassonJW commented on Sep 23, 2026

September 24 follow-up: exact gate recovered in place on 26.917.8451.0

xiaosheng2021 commented on Sep 26, 2026

s00llen commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions