[Windows App 26.820.7780.0] Second manual message can freeze before turn/start after cross-task message injection

What version of the Codex App are you using?

• OpenAI.Codex: 26.820.7780.0
• Bundled app server: codex-cli 0.150.0-alpha.8
• Chromium runtime: 151.0.7922.170

What platform are you using?

• Windows 11 Pro x64
• OS version: 10.0.26200 (build 26200)

What issue are you seeing?

A target task can become unable to submit its next manual composer message after it receives a message from another Codex task.

The cross-task message is delivered and rendered with the banner:

Sent by ChatGPT from another task

The target assistant can complete that turn normally. However, when the user types the next simple plaintext message in the target task and clicks Send, the Send button changes into a spinner/busy state and the UI becomes stuck. No new user turn appears and, critically, no corresponding app-server turn/start request is logged.

A full quit and relaunch of Codex Desktop restores the composer. The same manual follow-up then produces turn/start immediately.

This was encountered across three consecutive repair/validation attempts. Local inspection covered two prior repair tasks and the current reproduction. Earlier attempts incorrectly treated successful programmatic cross-task delivery as proof that the visible composer was fixed; it is not, because that path bypasses the failing renderer/composer submission path.

Steps to reproduce

1. Start a source task in Codex Desktop.
2. Create or open a separate local target task.
3. From the source task, send a prompt to the target using the built-in task/thread messaging capability.
4. Confirm that the target shows the cross-task banner and that the target assistant completes its reply.
5. Focus the target task.
6. Type a short plaintext follow-up in the visible composer, such as second-round test.
7. Click Send.
8. Observe that the Send control becomes a spinner/busy indicator, but the message is not submitted and no turn/start is emitted.
9. Fully quit Codex Desktop and relaunch it.
10. Return to the same task and send a short manual message again.
11. Observe that submission now succeeds.

Evidence

On the affected pre-restart app session:

• The target task had events for the preceding turn, but the failed manual click did not add another turn/start.
• The renderer logged state-reconciliation failures such as:

Item not found in turn state
Dropping commandExecution/outputDelta for missing item

• Other recent affected sessions also contained:

Received turn/started for unknown conversation
Rebinding placeholder latest turn to incoming event

After a full quit/relaunch, without changing the persisted task corpus or performing the planned metadata cleanup:

2026-08-26T04:42:22.061Z method=turn/start durationMs=23 errorCode=null
2026-08-26T04:43:57.765Z method=turn/start durationMs=317 errorCode=null

Those were the second and third messages sent through the visible composer after restart.

Additional controls:

• codex doctor --json --all reported authentication, network, WebSocket, and database-integrity checks healthy.
• Programmatic cross-task delivery remained functional, which shows that the target thread and backend were reachable while the visible composer path was stuck.
• The persisted state was unchanged across the recovery restart. This points to stale in-memory renderer/turn ownership or composer state rather than a backend outage.
• The local corpus is large (approximately 1,090 active tasks, a 425.6 MB logs_2.sqlite, and 7.3 GB of active rollout files). This may amplify the bug, but it is not a proven root cause: SQLite integrity was OK, and restart recovered submission without cleaning those files.

Task IDs, usernames, local paths, message contents, and raw logs are omitted for privacy. Sanitized excerpts can be provided if maintainers request them.

Expected behavior

• Receiving a cross-task message must not poison the target task's next manual composer submission.
• Clicking Send should either produce an authoritative turn/start or return an actionable error and restore the composer; it must not remain indefinitely busy before app-server submission.
• Renderer state should reconcile completed/incoming turns idempotently, including placeholder turns and events received for a task that is not currently focused.
• A full Desktop restart should not be required to send the next message.

Possibly related issues

• #24263 — renderer reload/rebind followed by Item not found in turn state
• #34255 — composer stops sending after switching among tasks
• #25779 — unbounded session/turn state meta issue
• #24287 — renderer loses active-turn/session state, though that report often involves prompts already accepted by the backend

This report is distinct because the failed click can be localized before turn/start, and the trigger involves a task that first received a message from another task.

Start by reproducing the cross-task message followed by a manual composer submission, and inspect renderer logs around the app-server turn/start entry point; codex doctor --json --all is a reported healthy control. Compare the pre-restart failure with post-restart recovery and determine whether completed or incoming turns leave stale ownership or composer state. Done means the next manual message submits or reports an actionable error without requiring a Desktop restart.