{"version":"2.1.271","anchor":"policy-limits-startup-wait-simplified-no-longer-blocks-on-r","canonical_anchor":"policy-limits-startup-wait-simplified-no-longer-blocks-on-r","heading":"Startup now explicitly waits for the policy-limits verdict","tier":"internal","area":"Policy Limits","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/policy-limits-startup-wait-simplified-no-longer-blocks-on-r","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### Startup now explicitly waits for the policy-limits verdict\n\nClaude Code startup can now explicitly wait (with a timeout) for the first policy-limits check to finish before continuing\n\n**Unclear.** The finding does not say what effect this has on cases where policy limits previously would have timed out.\n\n**What**\n\nStartup code that depends on organization policy limits (restrictions your admin can configure) now goes through a new `awaitColdStartVerdict()`\/`bin()` wait-with-timeout pair instead of the old load-and-wait routine.\n\n- The old startup routine, which called `ensureLoadRequested`\/`waitForLoad` with a timeout and recorded `completed`\/`timed_out` outcomes, was replaced with a simpler skip-check plus the new wait call.\n\n- The MCP (Model Context Protocol) cold-start sequence now waits up to a budget for the policy-limits verdict before expanding server config variables, logging if it times out and falling back to loading MCP configs without the verdict.\n\n- The wait records whether it `completed` or `timed_out` and reports its duration via a new metric.\n\n**Why**\n\nThis makes sure organization policy restrictions are known before dependent startup steps (like loading MCP server configs) proceed, while still timing out gracefully instead of hanging startup if the check is slow.\n\n- Area: Policy Limits\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}