{"version":"2.1.222","anchor":"permission-responses-are-checked-against-the-tool-they-were-","canonical_anchor":"permission-responses-are-checked-against-the-tool-they-were-","heading":"Permission responses are checked against the tool they were issued for","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.222\/e\/permission-responses-are-checked-against-the-tool-they-were-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.222","markdown":"### Permission responses are checked against the tool they were issued for\n\nA permission answer meant for a different tool is ignored, so nothing gets wrongly approved.\n\n**What**\n\nA can_use_tool answer that names a different tool than the one being asked about is now ignored, so a stale or crossed response cannot approve the wrong call.\n\n**Details**\n\n- both the SDK control-protocol client and the remote permission bridge record the pending tool name\n- the hook and permission response schema gained an optional toolName field\n- telemetry distinguishes a match from a mismatch\n- in the remote session manager, a mismatch is logged and the local prompt stays up rather than being dismissed, since the worker would drop the answer anyway\n\n**Evidence**\n\n`bridge_permission_toolname_check`, `worker will drop it, keeping prompt`\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 4\/5\n- Signal: 0\/5"}