{"version":"2.1.317","anchor":"permission-cards-can-be-denied-from-the-control-channel","canonical_anchor":"permission-cards-can-be-denied-from-the-control-channel","heading":"Permission prompts handled remotely can now be answered with a denial","tier":"notice","area":"Permissions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317\/e\/permission-cards-can-be-denied-from-the-control-channel","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317","markdown":"### Permission prompts handled remotely can now be answered with a denial\n\nA permission prompt answered through a remote connection can now be closed as denied, keeping the reply's message and interrupt choice\n\n**What**\n\nWhen Claude wants to do something that needs your approval, Claude Code raises a permission prompt. Sometimes another program shows that prompt and sends the answer back over a control connection, a link that program uses to steer Claude Code. In that setup each prompt is handled as a card, and a card can now be closed with a deny answer. The denial keeps two things from the reply:\n\n- the message that came with it\n\n- whether to interrupt\n\nClaude Code also now notes when the prompt at the front of the waiting list is an older one than the prompt whose answer is being recorded.\n\n**Why**\n\nThis affects how permission prompts in remote sessions are settled. It matters most when more than one prompt is waiting at the same time.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}