Answer accepted by question author
This is a core PowerShell architectural behavior, and your prior assessment is completely correct. There is no native configuration or environment variable that globally and permanently disables alias resolution in PowerShell 7.6.3. When you delete items from the Alias:\ drive within your $PROFILE script, you only clear the aliases present in the initial state of that specific runspace. As soon as you execute a utility requiring a module, PowerShell automatically initiates an import process. The engine reads the module's .psd1 manifest file and pulls all variables listed under the AliasesToExport key straight back into your active session.
Attempting to continuously force the deletion of these aliases during module loading would severely degrade console performance and inevitably break built-in utilities that depend on those exact abbreviations for their background tasks. The industry standard solution is to shift this strict enforcement from the console runtime into your authoring environment. By utilizing the official PowerShell PSScriptAnalyzer module within a script editor like Visual Studio Code, the environment evaluates your code against strict rules such as PSAvoidUsingCmdletAliases. It will immediately flag any typed alias and automatically suggest the fully qualified command name. This approach corrects your scripting habits in real-time while leaving the fundamental, required PowerShell architecture intact and fully supported.
Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.
VPHAN
-
MovelessMove-0585 250 Reputation points
Thank you for the explanation. We agree that alias resolution is at the engine level and cannot be permanently disabled. Therefore, it makes sense for the practical solution to be on the PSScriptAnalyzer side. Thank you.
Sign in to comment
