{"version":"2.1.300","anchor":"set-permission-mode-drops-settings-derived-modes-in-runner-c","canonical_anchor":"set-permission-mode-drops-settings-derived-modes-in-runner-c","heading":"Permission-mode changes can now say they came from settings, and runner children ignore them","tier":"notice","area":"Permissions","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300\/e\/set-permission-mode-drops-settings-derived-modes-in-runner-c","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.300","markdown":"### Permission-mode changes can now say they came from settings, and runner children ignore them\n\nA `set_permission_mode` request can now carry `from_settings`, and a runner child ignores settings-supplied modes and keeps its own\n\n**Unclear.** It does not say what makes a Claude Code process a runner child, so it is unclear which setups now lose a mode from settings.\n\n**What**\n\nThe permission mode controls how much Claude Code may do without asking you first. The message that changes it, the `set_permission_mode` control request, has changed in two ways:\n\n- It can now include `from_settings`, marking a mode that came from settings rather than from the user. The code that builds this request now takes a set of options instead of a single positional `ultraplan` argument.\n\n- A runner child, a Claude Code process started and controlled by another one, ignores a `set_permission_mode` request that has `from_settings` set. It replies with the mode it already has.\n\n**Why**\n\nA permission mode supplied by settings can no longer override the mode a runner child is already using. If you rely on settings to set the mode, it may not take effect in these child processes.\n\n- Area: Permissions\n- Names: `set_permission_mode`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: yes"}