{"version":"2.1.323","anchor":"permission-rules-that-look-like-secrets-are-no-longer-persis","canonical_anchor":"permission-rules-that-look-like-secrets-are-no-longer-persis","heading":"Permission rules that look like secrets are kept for the session only","tier":"notice","area":"Permissions","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/permission-rules-that-look-like-secrets-are-no-longer-persis","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Permission rules that look like secrets are kept for the session only\n\nAlways-allow rules that look like secrets, or that would land in a git-tracked settings.local.json, now stay unsaved\n\n**What**\n\nWhen you answer a permission prompt with \"always allow\", Claude Code turns your answer into a rule and saves it to a settings file. It now scans the rule first. In these cases the rule applies only to the current session and is not saved:\n\n- The rule looks like it contains a secret, such as a password or API key\n\n- The rule would be saved to `.claude\/settings.local.json` and git tracks that file\n\n- The scan itself fails\n\nEach case shows its own notice, for example \"Allowed for this session only. The rule looks like it contains a secret, so it isn't saved to settings.\" Before, every rule was saved.\n\n**Why**\n\nPasswords and API keys no longer end up in settings files that get committed to a git repository and shared. If a rule you expected to keep is not remembered next time, one of these notices explains why.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}