Windows: composer Send button stays disabled; voice and message editing still create turns

Summary

Codex Desktop for Windows repeatedly stops submitting messages written in the normal composer. The Send arrow remains grey and the typed message never becomes a user turn. The failure also occurs in newly created chats, sometimes after only one successful exchange.

Two alternate paths continue to work while the composer is blocked:

• Voice mode can create a new user turn in the same chat.
• Editing an already-sent message can deliver additional information.

This strongly suggests a client-side failure in the normal composer, its validation/state machine, or the handoff that creates a turn. It does not prove the exact component or root cause.

Environment

• Platform: native Windows installation, not WSL, VPS, or remote host.
• Windows: x64, NT build 26200.9445, display version 25H2.
• Codex Desktop release reported in app logs: 26.908.40834.
• Local app-server/CLI version reported in app logs: 0.154.0-alpha.6.2.
• Application logs: %LOCALAPPDATA%\Codex\Logs.
• Web profile: %APPDATA%\Codex\web\Codex.
• Local Codex state: %USERPROFILE%\.codex.

Reproduction

1. Open Codex Desktop on Windows.
2. Create a new chat.
3. Send a short message from the normal text composer.
4. After the first response, write another short message and try to send it.
5. Observe that the Send arrow remains grey and the message is not submitted.

The issue can also affect an existing chat. Closing and reopening the app does not reliably restore typed sending.

Expected result

The text is submitted, a user turn is created, and the local engine starts processing it.

Actual result

The text remains in the composer, the Send arrow stays grey, and no corresponding user message or turn start reaches the local engine.

Frequency and history

• Recurrent and reproducible, including in new chats.
• Windows Repair did not fix it.
• Reinstalling the app fixed it temporarily, but the failure returned after approximately one week.
• A normal close/reopen without file changes did not fix the current occurrence.

Controlled diagnostic capture

A lightweight 15-minute local monitor recorded filesystem metadata, filtered application errors, process state, and network state. It did not copy credentials, tokens, or full conversation content.

Observed around the manual failure marker:

• The preceding turn completed normally.
• No second user message and no new turn start appeared in the local session after the failed send attempt.
• The main Codex process remained responsive.
• TCP connections remained established; none were observed in SYN_SENT at the failure marker.
• No temporally matching HTTP 401, 403, 429, or 5xx errors were found.
• No matching general network, authentication, SQLITE_BUSY, or SQLITE_LOCKED error was found.
• No matching MCP lock or process-manager change was observed.
• Account usage limits were not exhausted.
• Cache and plugin activity existed earlier, but there is no evidence establishing either as the cause.
• An unknown conversation warning was associated with successful auxiliary title generation and is not sufficient to establish causality.

Important isolation result

While normal typed sending was blocked:

• Voice mode successfully created a new turn.
• Editing an existing message successfully delivered new information.

Both paths use the same account, chat, local engine, and general connectivity. Therefore a general account, quota, engine, or network outage is unlikely. The failure appears to occur before the normal composer creates a turn.

Cache test status

A reversible test was prepared to rename only:

%APPDATA%\Codex\web\Codex\Default\Cache

The first attempt aborted because the directory was temporarily unavailable after Codex closed. No cache directory was moved, no backup pointer was created, and no conclusion about cache can be drawn from that attempt. No session, history, credential, configuration, Local Storage, Session Storage, or database file was intentionally changed.

Current assessment

Observed facts

• Failure is specific to normal composer submission.
• Failed submission produces no user turn in the local engine.
• Voice submission and message editing remain functional.
• Restart, Windows Repair, and a previous reinstall have not provided a durable solution.

Working hypotheses, not proven

1. Stuck client-side composer validation or state machine.
2. Failure in the renderer-to-local-engine handoff specific to normal composer submission.
3. Corrupted regenerable UI cache or another persisted renderer state.

There is not enough evidence to identify a root cause or to attribute the issue to cache, plugins, MCP, authentication, or SQLite.

Questions for the Codex team

1. Is there a supported way to collect renderer/composer diagnostics on Windows when the Send button is disabled?
2. Which log event should appear when the normal composer accepts a submission but before a local turn starts?
3. Is there a known issue in release 26.908.40834 where voice/edit routes work but normal composer submission remains disabled?
4. Is there a supported, narrowly scoped reset for composer UI state that preserves sessions, history, credentials, settings, and databases?

Privacy and attachments

This report intentionally excludes conversation text, tokens, credentials, absolute user-profile paths, raw session transcripts, and raw application logs. Raw logs should be reviewed and redacted before sharing. They should not be posted publicly if they contain private project or account information.

Recommended public attachment: this report only.

Potential private attachment, if requested by OpenAI support: a redacted extract covering the failure window and the associated feedback/session ID.

Reproduce the disabled Send button on Windows and review the filtered logs under %LOCALAPPDATA%\Codex\Logs, comparing normal composer submission with the working voice and message-edit paths. Done means identifying and fixing the composer submission failure, with normal typed messages creating user turns again without regressing voice or editing.