{"version":"2.1.268","anchor":"trust-workspace-gains-a-stricter-mode-referencing-cli4415","canonical_anchor":"trust-workspace-gains-a-stricter-mode-referencing-cli4415","heading":"--trust-workspace gains a stricter mode referencing cli#44151, still on by default","tier":"use","area":"Trust","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/trust-workspace-gains-a-stricter-mode-referencing-cli4415","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### --trust-workspace gains a stricter mode referencing cli#44151, still on by default\n\n--trust-workspace help text now documents a stricter mode that drops repo-committed permission grants\n\n**What**\n\nThe help text for the `--trust-workspace` flag now documents a second, stricter enforcement mode. Setting `--trust-workspace` (or its environment variable) to `false` now triggers this stricter gate: permission grants committed to the repository's own settings (via `permissions.allow`) are dropped, with a warning like \"Ignoring N permissions.allow\" printed to the terminal. Instead, such grants have to live in the host machine's own `settings.json`, not the repo's.\n\n**Why**\n\nThis stops a checked-out repository from being able to grant itself extra tool permissions just by having them committed to its settings files. Anyone relying on repo-committed `permissions.allow` entries needs to move those grants to their local `settings.json` if they set `--trust-workspace` to false.\n\n- Area: Trust\n- Names: `permissions.allow`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 3\/5"}