Summary
PowerShell's variable names are case-insensitive, so a seemingly local variable named $home resolves to the built-in read-only $HOME variable. When a generated or agent-authored script intends to use $home as a scratch path and then runs cleanup such as Remove-Item -Recurse -Force $home, PowerShell can target the user's real profile directory instead of the intended temporary directory.
I've now seen this pattern multiple times in agent-generated PowerShell. In one case during Copilot CLI hook testing, this command shape attempted to remove content from the user profile before the process was stopped:
$home = 'C:\Users\name\.copilot\session-state\...\files\copilot-home-hooks'
if (Test-Path $home) { Remove-Item -Recurse -Force $home }Because $HOME is read-only, assignment failed, but subsequent references still pointed at the real home directory. That creates a high-risk corrupted-profile failure mode.
Why this matters
Copilot CLI frequently generates PowerShell for Windows users. $home is a natural variable name for directories like app home, tool home, temp home, or Copilot home. In PowerShell this is a dangerous footgun because it aliases the built-in $HOME variable by case-insensitive lookup.
Suggested mitigations
- Add a Copilot CLI/system instruction for PowerShell generation: never use
$home as a user-defined variable; use names like $userProfile, $homeDir, $copilotHomePath, or $targetRoot instead.
- Add a safety rule or lint-like guard before destructive PowerShell commands when the target variable is
$home/$HOME.
- Consider warning or requiring confirmation when generated PowerShell combines
$home with destructive recursive operations such as Remove-Item -Recurse.
This is especially important for autonomous/remote sessions where a user may not see the exact command before damage occurs.
Summary
PowerShell's variable names are case-insensitive, so a seemingly local variable named
$homeresolves to the built-in read-only$HOMEvariable. When a generated or agent-authored script intends to use$homeas a scratch path and then runs cleanup such asRemove-Item -Recurse -Force $home, PowerShell can target the user's real profile directory instead of the intended temporary directory.I've now seen this pattern multiple times in agent-generated PowerShell. In one case during Copilot CLI hook testing, this command shape attempted to remove content from the user profile before the process was stopped:
Because
$HOMEis read-only, assignment failed, but subsequent references still pointed at the real home directory. That creates a high-risk corrupted-profile failure mode.Why this matters
Copilot CLI frequently generates PowerShell for Windows users.
$homeis a natural variable name for directories like app home, tool home, temp home, or Copilot home. In PowerShell this is a dangerous footgun because it aliases the built-in$HOMEvariable by case-insensitive lookup.Suggested mitigations
$homeas a user-defined variable; use names like$userProfile,$homeDir,$copilotHomePath, or$targetRootinstead.$home/$HOME.$homewith destructive recursive operations such asRemove-Item -Recurse.This is especially important for autonomous/remote sessions where a user may not see the exact command before damage occurs.