{"version":"2.1.269","anchor":"new-headless-control-schema-list-permission-rules","canonical_anchor":"new-sdk-control-request-methods-gethookslisting-and-listper","heading":"New list_permission_rules API exposes a session's live permission rules","tier":"use","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269\/e\/new-headless-control-schema-list-permission-rules","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269","markdown":"### New list_permission_rules API exposes a session's live permission rules\n\nA new list_permission_rules control request and SDK method expose the same permission-rule list the \/permissions command shows\n\n**What**\n\n- 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 \u2014 including rules that aren't currently in effect (marked `notInEffect`) \u2014 each annotated with an editability tier (`persistent`\/`session`\/`readonly`).\n\n- 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.\n\n- 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.\n\n**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.\n\n- Area: SDK\n- Names: `list_permission_rules`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 3\/5"}