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)

1. Launch the desktop app normally and open an existing chat.
2. Type a follow-up message and try the send button or Enter.
3. On affected launches, the send control appears unavailable or remains loading, with no explanatory error. The follow-up does not start a model run.
4. Navigate to another chat and return: the loading appearance may disappear, but the unsent draft remains. This does not restore sending.
5. 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.
6. 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:

1. Identify the running app and its actual main Electron window by type window and URL app://-/index.html.
2. Reload that main window with webContents.reload(), preserving the backend process where possible.
3. Wait for readiness to become available and the configuration block to disappear.
4. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Start at the renderer-side local request manager, including pendingRequests and fetch-response handling, and trace codex-home initialization through the Electron main-process and renderer lifecycle. Add bounded failure or retry for stalled idempotent reads, a visible recovery action that preserves drafts, and regression coverage for delayed, missing, early, and out-of-order responses. Verify ordinary launches and existing-chat follow-up sends recover without a manual main-window reload or duplicate sends.