Windows Defender flags Codex computer-use helper as Trojan:Win32/ClickFix.DE!MTB

Codex
1

I’m reporting what looks like a possible Windows Defender false positive involving Codex Desktop.

Windows Security repeatedly showed “Threat blocked” / Severe for:

`Trojan:Win32/ClickFix.DE!MTB`

The affected resource shown through PowerShell was the Codex computer-use helper:

`C:\Users\ocean\AppData\Local\OpenAI\Codex\runtimes\cua_node\1b23c930bdf84ed6\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exe`

The command line included:

`codex-computer-use.exe turn-ended`

PowerShell checks showed:

`ActionSuccess: True`

`DidThreatExecute: False`

`IsActive: False`

I also ran a Windows Security scan afterward and it reported no threats.

Extra context:

- This is happening on my travel machine, not my main PC.

- I’m using a VPN through a travel router.

- The machine is isolated from my other devices on the network.

- It seemed to happen around the end of Codex turns, sometimes near when work like git pushes completed, but Defender’s resource pointed to Codex’s local helper, not git.exe or GitHub traffic.

- I updated Codex, fully exited all Codex instances, stopped leftover helper processes, and rescanned.

- I searched online and did not find many/any reports of this exact `codex-computer-use.exe` + `ClickFix.DE!MTB` combination.

The file hash I saw was:

`F2B2F56FCD1699B0FA32DEC3214A56A1D36B937A2ECF58CC822AB4A904551E03`

The executable also appeared to be unsigned when checked with `Get-AuthenticodeSignature`, which may be part of why Defender is suspicious.

I’m not asking people to ignore Defender warnings. I’m leaving the item blocked and not restoring/allowing it. I’m posting this to see if anyone else has seen the same detection and to help confirm whether this is a Defender heuristic false positive around Codex’s computer-use helper.

2

I would not whitelist it yet either. The useful next data is the packaging chain, not just the Defender name.

For a report like this I would include four things in one place: Codex Desktop version/build, Defender security intelligence version, the SHA-256 you already captured, and whether a clean reinstall produces the same hash under the same cua_node runtime path.

The unsigned helper detail is worth calling out separately. If the outer app installer is signed but the nested helper is not, Defender may be reacting to the helper’s behavior plus lack of signature, which is different from proving the binary is malicious.

I would also submit the exact file to Microsoft Security Intelligence as a possible false positive and keep it blocked until either Microsoft or OpenAI can confirm the expected hash/signing story.

3

Thanks, this is helpful. I’m not whitelisting/restoring it.

Update: this has now reproduced on my main PC too, completely separate from the travel router/VPN/laptop setup. Same Defender detection pattern, and it happened near the end of a Codex commit/turn. That makes me think this is less likely to be network/VPN-specific and more likely a Defender heuristic around Codex’s helper/turn-ended behavior.

Both machines show clean scans afterward, and I’m leaving the item blocked.

- Codex Desktop version/build: latest as of July 3, 2026

- Defender security intelligence version: `1.453.401.0`

- SHA-256 of the helper: `F2B2F56FCD1699B0FA32DEC3214A56A1D36B937A2ECF58CC822AB4A904551E03` from the first affected machine

still have to see:

- whether reinstall/update produces the same helper hash under the same `cua_node` runtime path

4

Im having the same problem as you.
Hash F2B2F56FCD1699B0FA32DEC3214A56A1D36B937A2ECF58CC822AB4A904551E03

5

Windows also constantly attempts to send codex config.toml to Microsoft, windows also called the config toml a “Threat” in the latest such attempt of a popup to get me send this simple config file as a sample, even though I completely disabled sample submission, which they apparently do not care about at all at Microsoft lmao

Windows is a mess, sadly.