Repository navigation
Technical Note: Windows Smart App Control (SAC) Compatibility & Event 3077 #8510
Description
Context:
I recently encountered a transient block on Windows 11 with Smart App Control (SAC) enabled. While global reputation has since resolved the issue for my local machine, I wanted to provide the logs to help prevent "Cold Start" blocks for other users on future releases.
The Issue:
Windows Code Integrity (Policy ID: VerifiedAndReputableDesktop) blocked the execution of ephemeral DLLs extracted to %TEMP%.
Log Evidence (Event ID 3077):
Code Integrity determined that a process (\opencode.exe) attempted to load \AppData\Local\Temp.3aeaf62d1f9feef5-00000000.dll that violated code integrity policy.
Log Evidence (Event ID 3033):
Code Integrity determined that a process (\opencode.exe) attempted to load \AppData\Local\Temp.3aeaf62d2e57eeed-00000001.dll that did not meet the Enterprise signing level requirements.
Observations:
The block was active on Jan 13, 2026, (1/13/2026 2:57:18 AM to 1/13/2026 9:09:15 PM) but resolved by Jan 14, 2026 (1/14/2026 10:20:08 PM), likely due to a global reputation update in the Microsoft Intelligent Security Graph.
Versions tested: v1.1.13 through v1.1.20.
Suggested Long-term Mitigations:
Code Signing: Formally signing the main binary and any dynamically loaded modules with a trusted certificate would bypass the "Unknown" reputation phase.
Binary Location: If possible, move the extraction of necessary dependencies from %TEMP% to a signed sub-directory within the installation path.
Hope this telemetry is helpful for Windows stability!
Activity
github-actions commentedon Jan 14, 2026
This issue might be a duplicate of existing issues. Please check:
These all relate to Windows security issues with DLL loading from temp directory and code signing. Your detailed technical documentation of the Smart App Control compatibility issue and the suggested mitigations (code signing and binary location changes) would be valuable reference material for addressing these related issues.
Feel free to ignore if your issue has a different focus.
AbubakarMahmood commentedon Jan 14, 2026
I’ve reviewed the suggested duplicates. While they are related to Windows security, my report specifically documents a Smart App Control (SAC) Code Integrity violation (Event ID 3077), which is distinct from the standard Defender 'Wacatac' false positives mentioned in #7919 and #8204. (Which I had encountered as well and went away using 'Exclusions' but still main problem remained).
My logs prove that SAC blocks the app's architecture of extracting unsigned DLLs to %TEMP% regardless of whether Defender flags it as a virus. This issue provides the specific technical path to a permanent fix: EV Code Signing and moving dependencies out of the Temp directory. I'll leave this open as a reference for the fix requested in #8087.
PS:
Exclusions are ignored: SAC operates at the Windows Kernel level via Code Integrity. Unlike standard antivirus scans, it does not respect Defender "Exclusions" or "Allow lists." If a binary does not meet the signing requirement, the kernel refuses to load it regardless of folder location.
No "Run Anyway": The "Run Anyway" button only appears for SmartScreen (reputation check). It does not appear for SAC when a process tries to load an unsigned DLL after the main app has already started.
AbubakarMahmood commentedon Jan 14, 2026
Most likely Smart App Control (SAC) flagged OpenCode as an LotL attack:
Windows Defender Smart App Control saw a legitimate, signed process (likely terminal or the npm runner) doing something suspicious that mimics an LotL attack:
Binary Dropping in Temp: Malicious scripts often download or "drop" a hidden .dll or .exe into the \AppData\Local\Temp folder because that folder is usually writable by any user.
Unsigned Code Execution: The script then tries to load or "run" that hidden file. Because the file was just created on the fly, it has no digital signature.
The Trigger: When OpenCode extracts an unsigned .dll into the Temp folder and then tries to load it into a running process, it follows this exact pattern. SAC can't tell the difference between "OpenCode doing its job" and "a hacker using a script to load a malicious DLL," so it blocks it to be safe.
This is why Code Signing is the only real fix—it tells Windows, "I am the one who created this temp file, and you can trust me"
jMerta commentedon Jan 16, 2026
I've ran into the same issue, can't work around it on my corporate laptop. Lowering version to v1.1.21 seems to work for now. All later updates cause the issue
github-actions commentedon Mar 26, 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