[BUG] APM self-update fails on Windows due to security policies

[GregoireBo]

Describe the bug

The APM self-update process fails during installation on Windows due to security restrictions. The downloaded binary (apm.exe) cannot be executed and returns an Access is denied error.

Additionally, the installer cannot verify the checksum because Get-FileHash is not available in the environment.

As a result, the update process aborts without fallback (Python not available either).

As a workaround, it is possible to manually download the desired version, place it into the versions directory, and update the launcher script to point to the latest version (what I had to do to update to 0.13.0), but this is not practical for regular use.

---

To Reproduce

Steps to reproduce the behavior:

1. Run command in a restricted environment:

   apm self-update

2. Let APM detect and download the latest version
3. Observe failure during binary execution

---

Expected behavior

The update process should:

• Successfully install the new version
• If security policy continue to block the process, provide a safe way to authorize execution for APM update

---

Environment (please complete the following information):

• OS: Windows
• Python Version: 3.14.0
• APM Version: 0.13.0 (attempting update to 0.14.0)
• VSCode Version (if relevant): N/A

---

Logs

PS <LOCAL_PATH>> apm self-update
[!] A new version of APM is available: 0.14.0 (current: 0.13.0)
Run apm update to upgrade

[i] Current version: 0.13.0
[>] Checking for updates...
[*] Latest version available: 0.14.0
[>] Downloading and installing update...
[*] Running installer...

===========================================================
                    APM Installer
             The NPM for AI-Native Development
===========================================================

Fetching latest release information...
Latest version: v0.14.0
Downloading apm-windows-x86_64.zip (v0.14.0)...
Download successful
Verifying download checksum...
Could not verify checksum (non-fatal): The term 'Get-FileHash' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Extracting package...
Testing binary...
Downloaded binary failed to run: Program 'apm.exe' failed to run: Access is deniedAt C:\Users\<LOCAL_USER>\AppData\Local\Temp\tmpktpixuky.ps1:540 char:23
+         $testOutput = & $exePath --version 2>&1
+                       ~~~~~~~~~~~~~~~~~~~~~~~~~.

Attempting automatic fallback to pip...
Python 3.9+ is not available - cannot fall back to pip.

Manual installation options:
  1. pip (recommended): pip install --user apm-cli
  2. From source:
     git clone https://github.com/microsoft/apm.git
     cd apm && uv sync && uv run pip install -e .

Need help? Create an issue at: https://github.com/microsoft/apm/issues
[x] Installation failed - see output above for details

---

Additional context

• 
• The issue may be related to enterprise Windows security policies blocking execution of downloaded binaries (restricted temp folder execution).
• The failure happens when running the binary from a temporary directory.
• It might help to:
  • Run the installer from a trusted directory
  • Sign the binary ?
  • Add guidance for restricted environments

[danielmeppiel]

RCA (analysis from a Mac, sources cited)

I traced the failure end-to-end through install.ps1, src/apm_cli/commands/self_update.py, and src/apm_cli/config.py. The "Get-FileHash not recognized" warning is a red herring -- the installer treats it as non-fatal (install.ps1:476, 507) and continues. The actual abort is OS-level application control denying apm.exe from %TEMP%.

What's happening

apm self-update writes the installer to %TEMP% via tempfile.NamedTemporaryFile(..., dir=get_apm_temp_dir()) (self_update.py:133-138; get_apm_temp_dir() defaults to system temp -- config.py:193-208). install.ps1 then creates its own temp dir, extracts apm.exe there, and runs the binary test from that temp directory:

install.ps1:314  $tempDir = Join-Path ([System.IO.Path]::GetTempPath()) ("apm-install-" + ...)
install.ps1:522  Expand-Archive -Path $zipPath -DestinationPath $tempDir -Force
install.ps1:540  $testOutput = & $exePath --version 2>&1   # <-- Access is denied

Only after the test does it Move-Item the package into %LOCALAPPDATA%\Programs\apm\releases\... (install.ps1:556-560). The OS rejects CreateProcess on the temp-path EXE before APM's code runs.

Root cause: AppLocker / App Control for Business (WDAC)

The signature -- "Program 'apm.exe' failed to run: Access is denied" on an unsigned EXE under %LOCALAPPDATA%\Temp -- is the textbook outcome of:

• AppLocker EXE rules restricting executables to %PROGRAMFILES% and %WINDIR% (Microsoft's recommended starter rule set per the AppLocker policies design guide), or
• App Control for Business / WDAC in enforcement mode with no publisher or hash rule for apm.exe. The Microsoft PowerShell team explicitly describes this enforcement pattern: "application control solutions are an incredibly effective way to drastically reduce the risk of viruses, ransomware, and unapproved software... PowerShell automatically detects when a UMCI policy is being enforced on a system" (PowerShell Constrained Language Mode, Microsoft DevBlog).

apm.exe is unsigned today (see scripts/windows/build-binary.ps1), so without a hash/publisher allow-list entry, any user-writable path is denied.

The Get-FileHash warning (secondary)

Get-FileHash has shipped in Microsoft.PowerShell.Utility since PowerShell 4.0 (cmdlet reference), so a CommandNotFoundException confirms an unusually constrained host -- typically $PSModuleAutoLoadingPreference = 'None' (a common hardening setting) or a JEA-style restricted session whose allow-list omits it (RestrictedRemoteServer sessions only expose 8 cmdlets per JEA session configurations). It corroborates the lockdown but does not cause the abort.

Why the fallback didn't save the user

Install-ViaPip requires Python 3.9-3.12. The user has Python 3.14, so the pip fallback also no-ops.

Failure attribution

Symptom	APM controls?	Evidence
EXE blocked from %TEMP%	No -- OS-level AppLocker/WDAC denies CreateProcess	install.ps1:540 runs & $exePath --version; OS returns Access is denied
Get-FileHash missing	Partially -- installer never Import-Modules and has no streaming fallback	install.ps1:490 calls Get-FileHash directly
Pip fallback unavailable	Yes -- Python 3.14 is outside the supported range	Install-ViaPip Python check
Install location	Yes -- always extracts + tests in %TEMP% before moving	install.ps1:314, 522, 560

Remediation (priority order)

1. Stop running the binary test from %TEMP%. Move-then-test: relocate the extracted package to $releaseDir under %LOCALAPPDATA%\Programs\apm\releases\... before & $exePath --version. %LOCALAPPDATA%\Programs is the conventional per-user install root (used by winget and Microsoft Store apps) and is commonly allow-listed by AppLocker baselines. This alone unblocks most restricted-environment users. Edit point: install.ps1:538-560.
2. Make the binary self-test policy-aware. When --version returns Access is denied / 0x80070005, surface a specific WDAC/AppLocker error message and link to the install-failures doc rather than silently jumping to pip.
3. Sign the released apm.exe -- the strategic fix for WDAC-managed estates. Track separately.
4. Robust Get-FileHash. Either Import-Module Microsoft.PowerShell.Utility -ErrorAction SilentlyContinue before line 490, or fall back to [System.Security.Cryptography.SHA256]::Create() over [IO.File]::OpenRead($zipPath) (core types -- allowed even in ConstrainedLanguage).
5. Document APM_TEMP_DIR (config.py:193-208 already supports an override) so users can point installs at an allow-listed path like %LOCALAPPDATA%\Programs\apm\tmp without code changes.
6. Widen Install-ViaPip to current Python (3.13/3.14) so the fallback is meaningful.

Scoped to this issue: #1 + #2 + #5. #3 is the durable cure; #4/#6 reduce noise.

I'm picking this up and will open a PR with #1, #2, #5, plus a Windows-only integration test that runs the move-then-test path on windows-latest.