[Desktop][Windows] Thread-control send/archive can hang without an observable result #41565

What version of the Codex App are you using?

Codex Desktop for Windows OpenAI.Codex 26.818.5345.0 (Microsoft Store package).

What platform is your computer?

Windows desktop.

What issue are you seeing?

The Codex Desktop thread-control tools can hang without returning a result, leaving it impossible to tell whether an operation applied:

• read_thread
• send_message_to_thread
• set_thread_archived

This is a data-safety problem for session cleanup: an archive or handoff must be treated as unknown when the call never acknowledges, so users cannot safely retry or move to the next source.

Reproduction observed

1. Start several read_thread calls concurrently.
2. Observe that the control call can remain pending for several minutes with no structured result.
3. Afterward, call send_message_to_thread or set_thread_archived for a different thread.
4. Those calls can also remain pending beyond a bounded wait, with no confirmation that the request reached the provider.
5. A later single read may succeed quickly, so the failure is intermittent rather than a total desktop-app outage.

The calls were stopped after bounded waits. No completion result or provider-state readback was returned. The send therefore remained unproven, and the archive state remained unknown.

Expected behavior

Every thread-control operation should either:

• return a bounded, structured success/error result; or
• return an operation ID immediately and expose durable status polling until a terminal state.

An unacknowledged operation must not leave callers unable to determine whether it applied.

Requested repair

1. Serialize or otherwise isolate app thread-control operations so concurrent reads cannot block later mutation requests.
2. Return an operationId immediately for send/archive operations.
3. Add durable status polling with a terminal result and explicit thread lifecycle state, including archived: true/false.
4. Require/support idempotency keys for send/archive operations.
5. On timeout, return a structured UNKNOWN — verification required response rather than hanging.
6. Add regression coverage for concurrent reads followed by send/archive, an injected delayed acknowledgement, and recovery without duplicate message or lost archive state.

The existing thread-handoff operation/status pattern is a useful model for this interface.

Safety workaround

Until this is fixed: persist a local recovery card before each operation, allow one thread-control operation at a time, stop after a short bound, do not blindly retry, and require both receiver readback and archive-state readback before calling a cleanup result complete.

No transcripts, task identifiers, account data, credentials, or local filesystem paths are included here.