If you've seen this error on Windows 11, you probably assumed your install was broken. Easy to think that. The tool dies at spawn. No Python traceback, no error inside the app. Nothing. The actual problem isn't your tool at all.
What's actually happening
Smart App Control (SAC) is Microsoft's consumer version of WDAC, the Windows Defender Application Control. When it's in enforcement mode it runs a policy called VerifiedAndReputableDesktop. That policy only lets executables run if they're signed by a trusted-root CA and known to Microsoft's reputation system.
Here's the catch: uvx, uv tool install, and pipx all generate small .exe launchers for your CLI at install time, and those launchers are unsigned. Authenticode says NotSigned. Code Integrity shoots the shim down before your tool ever starts. The tool is fine. The little launcher that boots it is what got blocked.
You can confirm it in Event Viewer under Applications and Services > Microsoft > Windows > CodeIntegrity > Operational. Events 3033 and 3077 are the blocks, and 3089 logs the signature info (you'll see TotalSignatureCount 0). If those are there, it's the policy, not your install.
If the same tool ran fine last week, check whether SAC got switched on in the meantime. That's usually the trigger.
How to keep working
Run the same code through a signed interpreter. This is the workaround that works today:
# instead of:
uvx browser-use
# run the module through Python instead:
uvx --from browser-use python -m browser_use.cli
Same idea inside a venv:
python -m browser_use.cli
python.exe is Microsoft-signed, so it sails through and the unsigned shim never executes. This works for any package with a runnable __main__ block, which is most CLI packages. If yours doesn't have one, call the library API directly instead of going through the CLI subprocess.
Don't bother looking for an allowlist. Consumer SAC has no per-app bypass. Microsoft is explicit about it: there's no way to allow one specific app. And don't turn SAC off to make a tool work either. It's binary, and once it's off the only way back is a clean reset of Windows. That's a terrible trade for one CLI.
The real fix is upstream. The only thing that fully unblocks an SAC-enforced machine is a signed release from the project. Neither uv nor pipx has a flag to sign the launchers it generates, so it's on the tool authors. Flutter ran into the same wall with its unsigned Dart runtime, so this isn't some browser-use-only quirk. If you're affected, say so on the issue. Maintainers pay attention when enough people show up.
The lesson
When a Windows CLI dies instantly with os error 4551, check the CodeIntegrity operational log before you reinstall anything. 3033/3077 means an unsigned launcher hit an App Control policy. The fix is usually to call the same code through a signed interpreter, not to chase a broken install.
And if you maintain a Python CLI, sign your releases. On an SAC-enforced machine, an unsigned launcher is a dead launcher, and there's no workaround your users can apply that fully fixes it.
