{"version":"2.1.281","anchor":"headlesssdk-message-loop-separate-queue-for-the-clients-o","canonical_anchor":"headlesssdk-message-loop-separate-queue-for-the-clients-o","heading":"Headless\/SDK message loop: separate queue for the client's own first-turn message","tier":"internal","area":"SDK","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/headlesssdk-message-loop-separate-queue-for-the-clients-o","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Headless\/SDK message loop: separate queue for the client's own first-turn message\n\nWhen Claude Code is driven by a program, the client's own first-turn message now waits in its own queue\n\n**Unclear.** The finding does not say what ordering problem, if any, this change fixes for SDK users.\n\n**What**\n\nIn headless mode (Claude Code driven by another program, for example through the SDK, instead of by a person at a terminal), incoming user messages can be held back until Claude Code is ready. A message flagged as the client's own first-turn message now waits in a separate queue. Other messages now also wait on a new first-turn gate, and closing input waits for both. The `cli_user_frame_parked` telemetry gains `own_first_turn_message` and `first_turn_gate`.\n\n**Why**\n\nThe program's own first message is kept apart from other incoming messages, so the first turn is handled before anything that arrives alongside it.\n\n- Area: SDK\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}