Installer mirror probe triggers Defender "blocked by your IT admin" toast

[boycez]

Summary

MicroClaw Installer triggers a Windows toast stating "This content is blocked by your IT admin" during installation on enterprise-managed devices.

This is caused by eager npm mirror probing, even when performing a same-version upgrade where Node.js, Git, OpenClaw, and required plugins are already installed and no network download is needed.

Evidence

Microsoft Defender Operational log records Event ID 1126 at the exact mirror-probe timestamps:

Your IT administrator has caused Microsoft Defender Exploit Guard
to block a potentially dangerous network connection.

Process Name: microclawinstaller.exe
Destination: https://registry.npmjs.org

and:

Process Name: microclawinstaller.exe
Destination: https://registry.npmmirror.com

Example correlation from the same installation:

16:37:08  MicroClaw Installer: Selecting fastest download mirror...
16:37:09  Defender Event 1126: registry.npmjs.org blocked
16:37:09  Defender Event 1126: registry.npmmirror.com blocked

Environment used for the repro:

• Windows build: 26310
• Microsoft Defender Network Protection: enabled (EnableNetworkProtection = 1)
• MicroClaw setup/installer: locally built and unsigned
• Existing MicroClaw installation
• OpenClaw version: 2026.7.1-1
• Same-version upgrade; no Node/Git/OpenClaw download was required

No corresponding AppLocker, Code Integrity, or SmartScreen block event was found.

Root Cause

WindowsSetup.__init__ eagerly resolves a mirror. When npm.registry is not explicitly configured, it calls _probe_fastest_mirror() immediately.

_probe_fastest_mirror() sends parallel requests to every candidate registry's /-/ping endpoint, including:

• registry.npmjs.org
• registry.npmmirror.com
• mirrors.cloud.tencent.com
• repo.huaweicloud.com

The request failures are caught by the installer, so installation may continue, but Defender Network Protection raises a user-visible enterprise-policy toast for the blocked destinations.

Defender file/path exclusions do not bypass centrally managed Network Protection URL policies.

Relevant code:

• deployer/windows_setup.py: WindowsSetup.__init__
• deployer/windows_setup.py: _probe_fastest_mirror
• deployer/windows_setup.py: setup_npm_mirror

Impact

• Produces a concerning and misleading system notification during installation.
• Adds approximately 4-7 seconds to repeat upgrades.
• Can generate multiple Defender notifications from one installation.
• Fresh installs may fail if the selected/fallback npm registry is also blocked.
• Current all-probes-failed fallback is npmmirror, which is blocked by policy in this environment.

Suggested Direction

• Remove network probing from WindowsSetup.__init__.
• Resolve mirrors lazily only when a component actually requires a network download.
• Skip mirror probing and npm registry writes on same-version/no-download upgrades.
• Prefer an explicit enterprise/user-configured npm.registry when present.
• Cache a previously successful registry instead of probing all public registries every run.
• Consider probing candidates sequentially rather than sending requests to every registry.
• Keep Defender file exclusions separate; do not treat them as a Network Protection workaround.

Acceptance Criteria

• A same-version upgrade with all dependencies present sends no outbound npm mirror probe requests.
• The same scenario produces no Defender Event ID 1126 for MicroClawInstaller.exe.
• Fresh installation still resolves a usable registry when downloads are required.
• Explicit npm.registry configuration is honored without probing unrelated registries.
• If all allowed registries are unavailable, the installer reports an actionable error rather than silently selecting a known-blocked fallback.

Notes

This issue intentionally captures the problem for later triage. It is not addressed by the current installation performance changes.