[BUG]

[chrisdoofer]

Describe the bug
Installatiuon fails at point of unzip and Defender blocks the unzip as irt believes ot contains a virus:

irm https://aka.ms/apm-windows | iex

===========================================================
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...
Checksum verified
Extracting package...
Testing binary...
Downloaded binary failed to run: Program 'apm.exe' failed to run: Operation did not complete successfully because the file contains a virus or potentially unwanted softwareAt line:639 char:23

•     $testOutput = & $stagedExe --version 2>&1
  

•                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~.
  

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

To Reproduce
Steps to reproduce the behavior:

1. Run command 'irm https://aka.ms/apm-windows | iex'
2. With parameters '....'
3. See error

Expected behavior
I would expect that this is a false positive and that APM should install normally.

Environment (please complete the following information):

• OS: Windows 25H2

Logs
If applicable, add any error logs or screenshots.

Additional context
Add any other context about the problem here.

[danielmeppiel]

PR #1408 (merged) partially addresses this — but doesn't fully fix it. Worth being explicit about what changed and what didn't:

What #1408 fixed

The installer now detects this specific Defender block (HRESULT 0x800700E1 / 'contains a virus or potentially unwanted software') and, instead of falling through to the generic 'Downloaded binary failed to run' message, prints targeted recovery guidance:

1. Verify the SHA256 of apm.exe against the published .sha256 sidecar before excluding it.
2. Add a Defender exclusion for the install directory (Add-MpPreference -ExclusionPath '...'), then rerun.
3. Install via pip install --user apm-cli as an alternative that avoids the binary entirely.
4. Help us clear the false positive by submitting the binary to Microsoft: https://www.microsoft.com/en-us/wdsi/filesubmission

What #1408 did NOT fix

• The underlying Defender block. apm.exe is an unsigned PyInstaller build, which routinely trips heuristic detectors. The real fix is code-signing the binary so it carries a publisher identity Defender (and SmartScreen) trusts. Tracked as a separate follow-up .
• Your specific failure mode also hit the pip fallback (Python 3.9+ is not available), so even with fix(install): detect Windows Defender AV block and emit specific guidance #1408 the installer would have exited the same way for you — it would just have explained the situation first and pointed at the exclusion + pip options. The pip-fallback-without-Python case is a separate gap.

Recommended actions right now (pre-signing)

If you still want to install on this machine today:

1. Confirm the SHA256 of apm-windows-x86_64.zip matches the .sha256 on the v0.14.0 release page.
2. Install Python 3.9+ (winget install Python.Python.3.12), then pip install --user apm-cli — this skips the PyInstaller binary entirely and won't trip Defender.
3. If you must use the binary, add an exclusion as above and rerun the installer.

Keeping this issue open until binary signing lands.

[sitiom]

This is also affecting Winget: microsoft/winget-pkgs#376283 (comment)

[danielmeppiel]

Thanks for the detailed report!

This is a Windows Defender ML heuristic false-positive on our PyInstaller-built apm.exe binary -- the same class of issue as #744. Defender's machine-learning classifier flags many PyInstaller one-file executables as suspicious because the unpacker stub pattern overlaps with techniques some malware uses, even though the binary is benign.

Existing mitigations already in place (see build/apm.spec):

• UPX compression disabled on Windows (UPX-packed binaries trigger far more AV heuristics).
• PE version metadata embedded (CompanyName, ProductName, FileVersion, etc.) so the binary is not an unsigned anonymous blob.

The remaining path forward is distribution work, not a code fix:

• Authenticode code-signing of the Windows binary with an EV or OV certificate.
• Submitting the binary to Microsoft via the Defender false-positive submission portal (https://www.microsoft.com/en-us/wdsi/filesubmission) so the ML model learns it is clean.

Closing as a duplicate of #744. Please reopen if a non-AV-heuristic repro emerges -- for example, actual malicious behavior observable in process telemetry (unexpected network calls, file writes, registry edits) rather than a static Defender verdict on the executable itself.