Desktop app: user_input dispatches immediately and websocket connects immediately, but first tool/model event is delayed by 7-10s

Summary

In the Codex desktop app, sending a message is dispatched immediately and the websocket connection is established almost immediately, but the first subsequent tool/model event often does not appear for ~7-10 seconds.

This does not look like the same issue as WebSocket fallback / 1008 Policy / reconnect-to-HTTPS. I do not see those markers in my local logs.

Environment

• Codex desktop app
• Current local version file shows: 0.121.0
• macOS
• Model in use: gpt-5.4

What I observed locally

From local codex-tui.log:

• op.dispatch.user_input happens immediately
• model_client.stream_responses_websocket ... codex_core::client: new happens in about 0.06s - 0.33s
• but the first ToolCall: often appears only after 7s - 10s

Representative sample:

• 2026-04-17T23:12:07.114883Z: op.dispatch.user_input
• 2026-04-17T23:12:07.178607Z: websocket client opened
• 2026-04-17T23:12:14.557435Z: first ToolCall:

That specific sample is about 7.44s from dispatch to first tool event, while websocket setup took only about 0.06s.

Other recent samples from the same log were similar:

• websocket establishment: 0.060s, 0.064s, 0.068s, 0.076s, 0.077s, 0.078s, 0.330s
• first tool event: 7.443s, 7.959s, 9.479s, 10.136s, 10.240s

Why I think this is different from #13041

I specifically checked my local logs for markers associated with the WebSocket fallback issue and did not find them:

• Falling back from WebSockets to HTTPS transport
• stream disconnected before completion
• 1008 Policy
• chatgpt.com/backend-api/codex/responses

So this seems more like:

• request dispatch is fast
• websocket establishment is fast
• but the server-side orchestration / planning / event emission path is delayed before the first actionable event is emitted back to the client

Impact

The app feels like send is slow, even though local dispatch is actually immediate. The perceived delay accumulates a lot in tool-heavy sessions.

Request

Could you confirm whether this is a known service-side latency issue in the desktop app path, and whether there is any client-side debugging flag that would expose where the 7-10 second gap is happening?