Group of 4 Use it now Notable
No documentation found
A new list_permission_rules control request and SDK method expose the same permission-rule list the /permissions command shows
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 plusworkspaceDirectoriesandoriginalCwd. This is the same information the/permissionscommand lists in the terminal, including rules from settings files, session-only approvals, slash-command grants, and--allowedToolsflag rules, each tagged with its source. - The SDK client class gained matching
getHooksListing()andlistPermissionRules()methods that issue theget_hooks_listingandlist_permission_rulescontrol 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.
Names in the bundlelist_permission_rules