{"version":"2.1.287","anchor":"sendfile-permission-and-approval-flow-reworked","canonical_anchor":"sendfile-permission-and-approval-flow-reworked","heading":"Approval steps for sending files reworked","tier":"notice","area":"SendFile","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.287\/e\/sendfile-permission-and-approval-flow-reworked","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.287","markdown":"### Approval steps for sending files reworked\n\nThe SendFile tool's permission check and approval flow were reworked, and refusals with a known reason are reported in one shared way\n\n**Unclear.** What difference this makes to the approval prompts you see is not clear, nor whether the tool is switched on for everyone.\n\n**What**\n\nThe SendFile tool sends files. Its permission check, which decides whether a file send may go ahead, has been reworked:\n\n- Approval first checks whether the send has already been approved, and then runs a separate permission step.\n\n- Refusals with a known reason are reported through the same refusal path that other refusals use.\n\n- In some cases, a refused send is no longer recorded as a usage event.\n\n**Why**\n\nThis rework can change when you are asked to approve a file send. For example, it can affect whether you are asked twice for the same send.\n\n- Flag `tengu_send_file`: Not enough to say (read for one account on one subscription tier against v2.1.287; this account: no value returned, anonymous baseline: no value returned, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: SendFile\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}