[Bug]: Codex Stop request followed by server-wide stalled turn starts on v0.0.45 #17468

Before submitting

• I searched existing issues. Related reports are linked below, but I did not find an exact match for this Codex incident on v0.0.45.
• I included the observed behavior and recovery evidence. A deterministic reproduction is not yet available.

Area

apps/server

Observed sequence

This was one observed incident, not a confirmed deterministic reproduction:

1. Codex threads stopped producing provider events while their sessions still appeared to be running.
2. Stop was requested for an affected thread. The server persisted thread.turn-interrupt-requested events, but no successful interruption was observed.
3. Later messages in affected threads, another existing thread, and newly created threads were accepted and persisted as thread.turn-start-requested events. They remained pending without starting provider turns.
4. Restarting the background service restored provider activity. A fresh message in an affected session received an agent reply.

The exact operation that blocked has not been identified. The ordering above does not prove that Stop caused the original provider stall.

Expected behavior

A failed or stuck provider operation should time out or surface an actionable error. It should not prevent unrelated threads from starting turns or handling Stop requests.

Actual behavior

Messages appeared to send successfully but agents never replied, including in new threads. The HTTP endpoint continued returning 200 and clients remained able to persist commands.

Impact

Blocks work completely until service restart.

Version or commit

Server runtime: 0.0.45. Desktop client: 0.0.45.

Environment

Linux headless background service; Codex app-server provider. Provider version was not captured during the incident.

Sanitized diagnostic observations

These are summaries of inspected state, not raw logs or fabricated log excerpts:

• Command receipts showed the later commands as accepted, with no command rejection recorded.
• Core thread projections had applied the latest persisted event sequence.
• Affected active threads had no pending approvals or user-input requests.
• Other existing/new threads had pending turns without subsequent provider-start events.
• Service task usage was below its configured limit and memory pressure was low when inspected. Earlier logs included Error: spawn git EAGAIN; whether that earlier condition contributed is unknown.
• After restart, previously stalled threads emitted fresh provider activity, the managed connection re-established, and a fresh-message reply was confirmed.
• Some requests queued before restart remained pending and needed a fresh follow-up.

Possible investigation direction

In v0.0.45 ProviderCommandReactor, provider intents pass through makeDrainableWorker(processDomainEventSafely), and the interrupt path awaits providerService.interruptTurn(...). The observed server-wide stall is consistent with a blocked shared worker, but no fiber dump or instrumented timeout identifies the exact blocking await.

Per-thread isolation, bounded provider operations, and visible timeout failures may help prevent a provider stall from blocking unrelated sessions.

Related reports

• [Bug]: Changing runtime mode mid-turn hangs ProviderCommandReactor; all new sessions stay Connecting or show no status #6517: older shared-worker lockout after a runtime-mode change with a different provider.
• Stop button leaves a thread stuck "Working" forever when the provider's abort fails #7368: older Stop failure leaving a thread running with a different provider.

Workaround

Back up session state, then restart the T3 background service. This restored replies without changing the installed version or deleting conversations. This is a recovery workaround, not a confirmed source fix.

No raw logs, database files, screenshots, prompts, session identifiers, host addresses, or local paths are attached.