{"version":"2.1.295","anchor":"initialize-toolaliases-now-validated","canonical_anchor":"initialize-toolaliases-now-validated","heading":"Tool aliases set at startup now go through the permission setup","tier":"notice","area":"SDK","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.295\/e\/initialize-toolaliases-now-validated","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.295","markdown":"### Tool aliases set at startup now go through the permission setup\n\nSetting `toolAliases` when a session starts now rebuilds the permission settings instead of storing the aliases directly\n\n**Unclear.** It is not clear whether aliased tools are now matched against permission rules differently than before.\n\n**What**\n\n`toolAliases` lets a program that starts Claude Code give tools other names. When it is set in the opening request that starts a session, Claude Code now rebuilds its permission settings (the rules that decide which tools may run without asking) to include the aliases. Before this change, the aliases were simply stored alongside those settings.\n\n**Why**\n\nThis may change how tool aliases and permission rules work together.\n\n- Area: SDK\n- Names: `toolAliases`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}