{"version":"2.1.311","anchor":"inherited-permission-answer-handling-rewritten-with-a-new-f","canonical_anchor":"inherited-permission-answer-handling-rewritten-with-a-new-f","heading":"Answers to resumed permission prompts are matched more strictly, and Deny now sticks","tier":"notice","area":"Permissions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.311\/e\/inherited-permission-answer-handling-rewritten-with-a-new-f","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.311","markdown":"### Answers to resumed permission prompts are matched more strictly, and Deny now sticks\n\nWhen a remote session resumes a parked permission prompt, answers that do not match are refused, and a Deny is kept instead of dropped\n\n**Unclear.** Whether the new checks apply depends on a server-side switch whose default is not known.\n\n**What**\n\nIn a remote session, a permission prompt can be parked: left waiting while the session is paused, then picked up again when it resumes. The handling of answers to these parked prompts has been rewritten.\n\nMatching answers to the right call:\n\n- Strict matching: a new handler rejects answers that cannot be read, that belong to another tool, or that do not repeat the call's input.\n\n- Timeout: it gives up after a wait, ending with `wait_lapsed`.\n\n- Refusal message: an unmatched answer refuses the call with: 'This tool call was refused and did not run: the permission answer for it could not be matched to this call.'\n\n- New flag: a new flag, `tengu_quizzical_knuth`, is added. Nothing has been read about it.\n\nHandling a Deny:\n\n- Deny as refusal: in a gated mode, a Deny is treated as a refusal.\n\n- Blanked Deny: a blanked Deny is matched by a suppressed request id.\n\n- Mismatched tool name: the Deny is rewritten rather than dropped.\n\n- Unreadable Deny: one that cannot be read yet is remembered, and the session keeps waiting.\n\n- Clear: a clear is sent after the Deny is queued.\n\n- Later answers: a later non-Deny answer for the same call is dropped, with a log line saying a Deny for it came first.\n\n- Before: there was one answer path, a Deny got no special handling, and a request id mismatch dropped the answer.\n\nWhen `tengu_eager_pillow` is on, the strict-answer path also passes the transcript's message rows. The flag server returned that flag on for this site's account and for the anonymous baseline; no reading has been taken under this release. Nothing has been read about `tengu_resume_parked_permission`.\n\n**Why**\n\nResumed permission prompts in remote sessions are less likely to approve the wrong call. When you deny one, the denial should actually take effect instead of being lost.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}