[macOS Desktop] New-chat first message stalls 10-16 min after fast thread/start; orphan thread is recreated

Bug report: Codex Desktop new chat first message is delayed before TurnInput reaches session loop

Summary

In ChatGPT/Codex Desktop on macOS, starting a new Codex chat and sending the first message can leave the UI spinning for a long time. Local logs show that thread/start succeeds immediately, but the first TurnInput is not submitted into the session loop until about 81 seconds later. Once TurnInput reaches the session loop, model execution proceeds normally and completes.

This suggests the delay is not model generation latency, not a full app-server crash, and not a long skills/frontmatter scan. The delay appears to be in the Desktop renderer/app-server boundary between successful thread/start and first-message TurnInput dispatch.

Environment

• App: ChatGPT Desktop / Codex Desktop
• OS: macOS
• ChatGPT app version: 26.903.61454
• ChatGPT app bundle version: 8378
• Bundled Codex CLI: codex-cli 0.153.4
• Codex originator in session: Codex Desktop
• Model selected in the delayed thread: gpt-5.5
• App-server processes observed during capture:
  • /Applications/ChatGPT.app/Contents/Resources/codex -c features.code_mode_host=true app-server ...
  • /Applications/ChatGPT.app/Contents/Resources/codex app-server --listen stdio://

Reproduction

1. Open ChatGPT/Codex Desktop on macOS.
2. Start a new Codex conversation.
3. Send a tiny first message such as 你好.
4. Observe that the new chat can remain spinning for a long time before any visible response.

This is intermittent. Existing chats usually respond normally; the issue primarily appears on newly-created chats and their first message.

Captured Example

• Thread URL: codex://threads/01a08a70-e5c4-7810-89c1-1c98f1e5a605
• Thread ID: 01a08a70-e5c4-7810-89c1-1c98f1e5a605
• Thread name generated later: 回应中文问候
• User prompt: 你好

Timeline from local logs

All times are local time, CST / Asia-Shanghai, on 2026-09-10.

• 16:30:49.797: session payload timestamp for the new thread.
• 16:30:49.862: thread/start request is logged; shell snapshot succeeds for thread 01a08a70-e5c4-7810-89c1-1c98f1e5a605.
• 16:31:06 through 16:32:10: a diagnostic script polling every 2 seconds does not see a rollout file for this thread.
• 16:32:11.138: first Submission ... TurnInput for the prompt 你好 appears in codex_core::session::handlers.
• 16:32:11.531: session_meta is written to the rollout file.
• 16:32:11.759: model request begins for the delayed turn.
• 16:32:41.846: final assistant message is written.
• 16:32:42.737: task_complete.

Observed delay:

• About 81 seconds between successful thread/start and first TurnInput submission.
• About 31 seconds between TurnInput submission and task_complete.

Evidence From Rollout File

Rollout file:

~/.codex/sessions/2026/09/10/rollout-2026-09-10T16-30-49-01a08a70-e5c4-7810-89c1-1c98f1e5a605.jsonl

Relevant event sequence:

0  2026-09-10T08:32:11.531Z  session_meta
1  2026-09-10T08:32:11.531Z  event_msg task_started
5  2026-09-10T08:32:11.545Z  turn_context
7  2026-09-10T08:32:11.753Z  event_msg item_completed  "你好"
23 2026-09-10T08:32:27.107Z  token_usage_record
33 2026-09-10T08:32:41.844Z  event_msg item_completed final assistant message
34 2026-09-10T08:32:41.846Z  response_item message
37 2026-09-10T08:32:42.737Z  event_msg task_complete

Evidence From logs_2.sqlite

thread/start succeeds early:

2026-09-10 16:30:49.862900000 INFO codex_core::shell_snapshot
app_server.request{otel.name="thread/start" rpc.method="thread/start" app_server.client_name="Codex Desktop" app_server.client_version="26.903.61454"}:
app_server.thread_start.create_thread:
thread_spawn:
session_init:
environments.resolve:
shell_snapshot{thread_id=01a08a70-e5c4-7810-89c1-1c98f1e5a605}:
Shell snapshot successfully created

First TurnInput is delayed:

2026-09-10 16:32:11.138905000 DEBUG codex_core::session::handlers
session_loop{thread_id=01a08a70-e5c4-7810-89c1-1c98f1e5a605}:
Submission sub=Submission {
  id: "01a08a72-2382-7802-a190-15f4551ffbd0",
  op: TurnInput {
    request: TurnInputRequest {
      input: UserInput {
        content: [Text { text: "你好\n" }],
        client_id: Some("98020e4f-1f65-4631-bfaa-9b3df55b3d4f")
      },
      ...
      start: TurnStartOptions { turn_trigger: Some("composer"), ... }
    },
    mode: StartOrSteer,
    ...
  }
}

After TurnInput, execution is normal:

2026-09-10 16:32:11.759 model request begins
2026-09-10 16:32:41.846 response_item message
2026-09-10 16:32:42.737 task_complete

Likely Boundary

The most likely failing boundary is:

Codex Desktop renderer / composer
  -> app-server new thread first-message binding or dispatch
  -> session_loop TurnInput submission

The evidence does not currently distinguish whether:

1. the Desktop renderer delays sending the first turn_input, or
2. app-server receives it earlier but delays dispatching it into the session loop.

However, the local evidence does narrow the issue to the period after successful thread/start and before Submission ... TurnInput.

Ruled Out By This Capture

• Not a full app-server crash: app-server processes remained alive.
• Not model generation latency: model request starts only after the 81-second gap; after that it completes normally.
• Not a long skills/frontmatter scan: skills warnings/errors occur after TurnInput, around 16:32:11, and complete within hundreds of milliseconds.
• Not only UI rendering: in this capture the rollout file itself does not exist or appear in polling until after the delayed TurnInput.

Related Warnings Observed But Probably Not Primary Cause

These warnings/errors appeared only after TurnInput was finally dispatched, so they do not explain the 81-second delay:

icon path with '..' must resolve under plugin assets/
skills scan reached its traversal limit (root: file:///Users/roger/.agents/skills)
skills scan reached its traversal limit (root: file:///Users/roger/.codex/skills)

Attachments / Private Logs Available

I can provide private logs if needed, but I am not attaching full raw transcripts publicly because they may include local paths, user workspace details, or session content.

Available local files:

~/.codex/sessions/2026/09/10/rollout-2026-09-10T16-30-49-01a08a70-e5c4-7810-89c1-1c98f1e5a605.jsonl
~/.codex/logs_2.sqlite
~/Desktop/启动缓慢排查.md

Start with the thread/start path and codex_core::session::handlers where Submission TurnInput is logged. Compare the Desktop renderer’s first-message dispatch with app-server handling using logs_2.sqlite and the rollout JSONL. Done means the responsible boundary is identified and the new-chat first message no longer has the reported gap.