{"version":"2.1.312","anchor":"apply-flag-settings-can-now-precede-claim-session-and-refuse","canonical_anchor":"apply-flag-settings-can-now-precede-claim-session-and-refuse","heading":"A spare session refuses claim_session when its flag settings were not applied","tier":"notice","area":"SDK","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.312\/e\/apply-flag-settings-can-now-precede-claim-session-and-refuse","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.312","markdown":"### A spare session refuses claim_session when its flag settings were not applied\n\nA pre-warmed spare process started with --await-claim now refuses claim_session if an apply_flag_settings is unanswered, refused or not in force\n\n**What**\n\nA program that drives Claude Code can start a spare process ahead of time with `--await-claim` and hand it to a user later by sending `claim_session`. Settings for that spare are sent with `apply_flag_settings`. The claim can now be refused if those settings did not take effect.\n\n- The `claim_session` handler gets a new `parkedSettingsRefusal` callback. It returns `claimRefusal()` from the object that tracks parked settings.\n\n- The claim is refused while an earlier `apply_flag_settings` is still unanswered: \"an earlier apply_flag_settings is still unanswered; claim again once it is answered\".\n\n- It is also refused when the latest `apply_flag_settings` was refused, or when a flag-settings key would not be in force.\n\n- The error reads `settings_not_applied: ... - nothing was claimed; start the session with query()`.\n\n- This applies only to the spare process started with `--await-claim`.\n\n- The `claim_session` description now says to send an `apply_flag_settings` carrying the MCP and plugin keys ahead of the claim, and that refusing those settings also refuses the claim. Before, it said to send `set_model`, `set_max_thinking_tokens` and `apply_flag_settings` right behind the claim.\n\n- `apply_flag_settings` now waits for a settle step tied to each request instead of a fixed sequence. Plugin-forwarding patches still use the `plugin_forwarding_patch_refused` path.\n\n- The builder for the initialize payload takes one more argument.\n\n**Why**\n\nA host can no longer claim a pre-warmed session whose settings never took effect, so a session does not start with the wrong MCP servers or plugins. Hosts should send the MCP and plugin settings before the claim, and be ready to start with `query()` when the claim is refused.\n\n- Area: SDK\n- Names: `claim_session`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: yes"}