Windows Defender FileFix signature blocks the PowerShell tool's composed inline commands; surfaces only as bare 'EPERM uv_spawn pwsh.exe'

Summary

On Windows 11 with Defender real-time protection at default settings, the PowerShell tool's composed command line can match Defender's Trojan:Win32/FileFix.BBA!MTB behavioral signature. Defender then blocks the pwsh process launch, and the failure surfaces to the model and user only as:

EPERM: operation not permitted, uv_spawn 'C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe'

No stderr, no hint of Defender involvement. In our session this cost several wasted, billed turns of retry and probing, and was only diagnosed because the user happened to see the Windows Security trojan toasts at the same moment and said so.

Environment

• Claude Code desktop app, Windows 11 Pro
• PowerShell tool runtime: pwsh 7.6.5 (Microsoft Store / WindowsApps app-execution alias)
• Windows Defender real-time protection, default configuration (no exclusions)

What happened

Three consecutive PowerShell tool calls failed at spawn with the bare EPERM above, while short commands - including file writes via cmdlets - ran fine before, between, and after. The Defender operational log (events 1116/1117) and Get-MpThreatDetection show one detection per failed call:

• Threat: Trojan:Win32/FileFix.BBA!MTB
• Resource type: CmdLine - the harness-composed line pwsh -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command <utf8 preamble>; <tool call body>; <exit-code/pwd epilogue>
• Action: Remove (the process launch was blocked); no file quarantined; DidThreatExecute: False

Trigger shape

The three flagged calls all had an inline body of roughly this form (~1-2 KB, multi-line):

$t = [System.Text.Encoding]::ASCII.GetString([System.IO.File]::ReadAllBytes($path))
$t2 = $t.Replace($anchor1, $new1).Replace($anchor2, $new2)
[System.IO.File]::WriteAllBytes($path, [System.Text.Encoding]::ASCII.GetBytes($t2))

i.e. read a document as bytes, patch content, write bytes back - an ordinary, benign editing pattern for an agent. The FileFix signature family targets social-engineering attacks that trick users into pasting PowerShell one-liners, whose shape is exactly a long inline -Command doing byte-level file surgery under -ExecutionPolicy Bypass. The harness's composed command line reproduces that shape wholesale.

Moving the identical logic into a script file on disk and invoking it with a short command line ran immediately and cleanly - the body never appears in the AMSI-visible command line.

Why this matters beyond one machine

1. Diagnosability. The model gets a bare EPERM at spawn. It cannot distinguish a Defender block from a sandbox restriction, a broken alias, or a transient OS error, and there is nothing in-band to correlate. Retries are guaranteed to fail and are billed. Without the user's out-of-band observation this was undiagnosable.
2. Likelihood. Long inline -Command bodies that read/patch/write files are routine agent behavior on Windows. Any Claude Code user with default Defender can hit this, and it will present as flaky EPERM spawn failures with no visible cause - likely already appearing in the wild as unexplained PowerShell tool flakiness.

Requests

• When a spawn on Windows fails with EPERM/access-denied, surface a hint that security software may have blocked it (or check the Defender operational log for a matching 1116/1117 event and say so). Even a one-line hint in the tool error would have saved the whole diagnostic detour.
• Consider materializing long -Command bodies to a temp .ps1 invoked by path, so the logic never rides the command line. This both shortens the AMSI-scanned surface and avoids the paste-attack shape the signature targets. (There may be AMSI script-scanning tradeoffs; the current shape is the worst of both.)
• Consider reporting the false-positive interaction to Microsoft: the harness's fixed preamble (-NoProfile -NonInteractive -ExecutionPolicy Bypass -Command try { $PSDefaultParameterValues['Out-File:Encoding'] = 'utf8' } ...) is a stable fingerprint that could presumably be distinguished from the attack pattern.

Related

Issue #90704, filed the same day from the same environment, covers an unrelated model-behavior incident; this one is harness/environment-level, hence filed separately.