You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows Defender falsely flags new releases as trojans #3415
Summary
Recent OpenCode Windows release assets are being flagged by Windows Defender with ML/heuristic signatures (e.g. Trojan:Script/Wacatac.C!ml, Program:Script/Wacapew.A!ml). Based on prior reports and cross-checks, this appears to be a recurring false positive, not evidence of compromise.
Affected / reports
2025-10-24: v0.15.16 quarantined by Windows Security as Trojan:Script/Wacatac.C!ml (Windows 11 Pro)
Prior threads showing the same class of detection:
Hypothesis
This is a heuristic / ML false positive common to bundled CLI/GUI binaries (compression/packing, embedded resources, or unsigned artifacts) and often “goes away” after Defender definition updates. No evidence of compromise has been presented.
What we’ll do
Publish checksums (SHA256) for all release assets.
Code-sign Windows artifacts (Authenticode; timestamped) to reduce AV false positives.
Generate an SBOM (CycloneDX) and attach to releases.
Avoid packers (e.g., UPX) for Windows release builds if used.
Add CI AV scans for every release: Windows Defender (Windows runner), ClamAV (Linux runner), and OWASP Dependency-Check for dependencies. If any scanner flags, CI will fail and post logs.
Submit false positives to Microsoft with SHA256 + sample upload whenever a Defender flag occurs.
Track detections in this issue with dates, signatures, engine/sig versions, and hashes.
Don't know if it's any help, but I encountered it on a Debian machine running wdavdaemon (#3388, maybe should've written it here)
It would help me figure this out if you could take a look at this pr on my fork and look at the defender workflow specifically. I have no idea what I'm doing with defender, but I have the other workflows working as secondary verification that there aren't any viruses so we could automaticly compile a report to send off to microsoft to get ahead of user's experiencing the false positives. @Sacquer
Interesting that this occurs on much older versions still.
I danced with this issue today for v1.1.12, and found I could get windows to shut up after explicitely installing 1.1.8. Not sure why this version specifically is working for me.
I was testing versions on my work machine, where I don't have the luxury of allowing threats.
Heres my steps for getting it to work (for my setup, wezterm, powershell, opencode via npm -g):
Activity
github-actions commentedon Oct 24, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
Sacquer commentedon Oct 25, 2025
Don't know if it's any help, but I encountered it on a Debian machine running
wdavdaemon(#3388, maybe should've written it here)riatzukiza commentedon Oct 26, 2025
It would help me figure this out if you could take a look at this pr on my fork and look at the defender workflow specifically. I have no idea what I'm doing with defender, but I have the other workflows working as secondary verification that there aren't any viruses so we could automaticly compile a report to send off to microsoft to get ahead of user's experiencing the false positives.
@Sacquer
Sacquer commentedon Oct 27, 2025
Sadly I don't think I'm much of help here, don't use Windows or PowerShell @riatzukiza 😿 .
Tyler-widd commentedon Oct 30, 2025
Workaround -

Settings
Virus & threat protection
Protection history
Find the opencode entry
Select allow on device
Sacquer commentedon Oct 30, 2025
Think you might be able to tell the daemon to ignore certain directories as well, for those that run in daemon mode, i.e. without a UI.
jimroberts-tamu commentedon Dec 17, 2025
I believe that the problem is that the installer does not have a publisher and in turn Windows marks the uninstaller EXE as "Blocked".
As a workaround you can right click on the uninstaller in Explorer and there will be a check box for "Unblock". Check that, click OK.
The root cause though is that the uninstaller is missing a publisher.
Edit: This is most likely the same issue that you will encounter when running the when you are prompted to upgrade to 1.0.164.
Xavier-Burger commentedon Jan 10, 2026
Interesting that this occurs on much older versions still.
I danced with this issue today for v1.1.12, and found I could get windows to shut up after explicitely installing 1.1.8. Not sure why this version specifically is working for me.
I was testing versions on my work machine, where I don't have the luxury of allowing threats.
Heres my steps for getting it to work (for my setup, wezterm, powershell, opencode via npm -g):
#7655 (comment)
Mirrowel commentedon Jan 11, 2026
This is a common windows defender L. This can trigger for archives with no binaries whatsoever.
WIndows defender is nothing but trouble - disable it.
Makishima commentedon Jan 11, 2026
@riatzukiza Just to be fair, could you please upload the file to https://www.virustotal.com/gui/home/upload?
nUser0 commentedon Jan 12, 2026
The suspicious file is blocked, but the open code function works normally. It means that the dll it releases is not necessary?
nUser0 commentedon Jan 12, 2026
It seems that the result of blocked files is that automated tests cannot run?
rekram1-node commentedon Jan 12, 2026
I think we need code signing to prevent this
github-actions commentedon Mar 28, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.
Hona commentedon Mar 29, 2026
As of OpenCode v1.3.4 across the CLI + Desktop apps, we have full code signing - so there should be no more warnings.
Please let me know otherwise