What probably matters to youSection of the release
What
A new unified function assembles a de-duplicated list of every allow/deny/ask permission rule in effect, drawn from context config plus, for managed installs, every settings-source layer — including rules that aren't currently in effect (marked notInEffect) — each annotated with an editability tier (persistent/session/readonly).
A new control request subtype, list_permission_rules, exposes this same data over the control channel/SDK: the session's live permission rules plus workspaceDirectories and originalCwd. This is the same information the /permissions command lists in the terminal, including rules from settings files, session-only approvals, slash-command grants, and --allowedTools flag rules, each tagged with its source.
The SDK client class gained matching getHooksListing() and listPermissionRules() methods that issue the get_hooks_listing and list_permission_rules control requests, with matching handlers in the control-request dispatcher.
Why
This lets SDK integrations and other tooling inspect a session's effective permission rules programmatically, the same way a person can with /permissions in the terminal.
