{"version":"2.1.257","anchor":"new-hostcredential-permission-decision-source-and-consent","canonical_anchor":"new-hostcredential-permission-decision-source-and-consent","heading":"Consent and host-credential scaffolding for approval withdrawal","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257\/e\/new-hostcredential-permission-decision-source-and-consent","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.257","markdown":"### Consent and host-credential scaffolding for approval withdrawal\n\nA hostCredential permission source and a reserved consent envelope key are in place, with nothing yet setting or reading them.\n\nApproval-related plumbing gained a distinct 'withdrawn' outcome: a new user-facing message is shown when an approval answer arrives for a request that was already withdrawn, and a new set of terminal reasons (`no_answer`, `host_withdrawn`, `superseded`) plus a `consent` field were added to the tracked fields for tool-use records.\n\nThe permission-decision source enum gained a `hostCredential` entry (joining `session`, `toolsNarrowing`, `mcpServerPolicy`), and the reserved tool-envelope keys list gained `consent` alongside `tool`\/`tool_use_id`, with envelope-building code now explicitly stripping a `consent` field into the shadowed-keys bucket. This looks like scaffolding for a host-mediated tool-consent\/credential flow; no in-bundle caller was found that actually sets or reads a `consent` value on a tool envelope, nor a UI path that surfaces the withdrawal message.\n\n- Area: Permissions\n- Names: `hostCredential`, `consent`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}