{"version":"2.1.273","anchor":"new-strict-parked-permission-answer-lane-defined-but-never","canonical_anchor":"new-strict-parked-permission-answer-lane-defined-but-never","heading":"New \"strict\" parked-permission answer lane defined but never selected","tier":"soon","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273\/e\/new-strict-parked-permission-answer-lane-defined-but-never","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273","markdown":"### New \"strict\" parked-permission answer lane defined but never selected\n\nA new stricter permission-answer matching path exists in the code but isn't yet used\n\n**What**\n\nClaude Code has a mechanism for \"parking\" a permission request (asking whether a tool can run) and later matching it up with the answer that comes back. A new, more conservative matching path called `routeStrictAnswer` has been added for this. It carefully re-checks the request ID, the specific tool call ID, the tool name, and that the tool call is still the most recent one before accepting an answer, rejecting mismatches for reasons like `not_the_park`, `decided`, `tool_name_mismatch`, or `not_queued`. This new path only runs when an internal setting is set to `\"strict\"`, and nothing in this change actually turns that setting on.\n\n**Why**\n\nThis is groundwork for tighter, less error-prone matching of permission answers to the right tool call, guarding against stale or mismatched approvals slipping through. Since nothing currently selects the `\"strict\"` mode, it has no visible effect yet.\n\n- Area: Permissions\n- Tier: Nothing to try yet\n- Useful: 4\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}