Windows Smart App Control blocks official tunnel-client v0.0.14 (unsigned Windows amd64 binary)

[rainingsnow0914tw-ship-it]

The official Windows amd64 full-client release v0.0.14 cannot start on a Windows 11 system with Smart App Control enabled. Windows reports that an application control policy blocked the file; CodeIntegrity events 3033 and 3077 report failure to meet signing requirements under policy 0283ac0f-fff1-49ae-ada1-8a933130cad6. Authenticode reports NotSigned.

Verified release: https://github.com/openai/tunnel-client/releases/tag/v0.0.14

• Asset: tunnel-client-v0.0.14-windows-amd64.zip
• ZIP SHA256: 784ab8da7b5a88f0109f1fd8aaf0a1c86067430b896dddf307ef7e3cc49fa1a5, matching the GitHub release asset digest.
• Extracted executable SHA256: fcc85a69ec0ad82518e4f8964f60c45e31787957782a0fc9c1b0c44e82d61b9b, identical to the installed executable.
• Even invoking tunnel-client.exe run --help is blocked before runtime authentication.
• The local Node MCP server responds correctly; existing tunnel metadata authentication succeeds. The disconnected connector returns HTTP 404.

Please provide a Windows build with a valid trusted Authenticode signature, or an official resolution that preserves Smart App Control. We have not disabled protection or attempted to evade the block. Is signing planned, and is a supported signed distribution available?

Microsoft documents that Smart App Control does not offer an individual-app exception and recommends a valid developer signature: https://support.microsoft.com/en-us/windows/security/threat-malware-protection/smart-app-control-frequently-asked-questions

[minaka-project]

We also observed a Smart App Control block when launching the official v0.0.12 binary. Here are a few additional data points that may help.

In our case, the file that was blocked was the official v0.0.12 tunnel-client.exe. The failure surfaced as:

OSError: [WinError 4551] An Application Control policy has blocked this file

At the same timestamp, Microsoft-Windows-CodeIntegrity/Operational recorded events 3033, 3077, 3089, and 3118 (the same Policy ID 0283ac0f-fff1-49ae-ada1-8a933130cad6 reported above). Event 3118's message text is literally "Smart App Control Block Deteails" (quoted verbatim, including what appears to be a typo in the Windows-provided string).

We also statically inspected the official Windows amd64 releases of v0.0.13 and v0.0.14 (downloaded from the GitHub Releases page; not executed):

• Both ZIP archives' SHA-256 matched the published SHA256SUMS.txt exactly.
• Get-AuthenticodeSignature reports NotSigned for tunnel-client.exe in both v0.0.13 and v0.0.14 (no signer certificate, no timestamp).

We have not run v0.0.13 or v0.0.14 ourselves, so we can't say whether they would be allowed or blocked, or whether they're otherwise compatible with our setup — this is separate from the v0.0.14 runtime result reported above in this issue.

One more data point: the same-hash v0.0.12 binary had run successfully in this same environment before. It later began being blocked with no local change to the file itself. We don't know why the outcome changed and aren't assuming a specific cause.

Like the original report, we'd like to keep Smart App Control enabled rather than disabling it, so we're also interested in a signed build or another officially supported path that preserves it.