Windows Defender repeatedly prompts to submit .codex\config.toml; one prompt showed the same path twice

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30527

Powered by Codex Action

same for me

Cross-linking #31419 because both reports involve Microsoft Defender reacting to normal Codex activity on Windows, although they may not share the same root cause.

#31419 involved codex-computer-use.exe being detected as Trojan:Win32/ClickFix.DE!MTB, which appears to have stopped after a Defender update. This issue involves repeated sample-submission prompts for .codex\config.toml.

A user in this OpenAI Community thread reports that the config.toml prompts continued even after automatic sample submission was disabled. I have not independently verified that setting, so I’m sharing it as a potentially useful connection rather than claiming a confirmed reproduction.

It may be worth checking whether Codex is repeatedly rewriting/touching config.toml, and whether the prompts correlate with Codex startup, plugin reconciliation, or Defender intelligence updates.

I can confirm this on another Windows 11 PC. The behavior is still recurring on 2026-07-14 (KST) with a current Codex Desktop build.

Observed

• At 19:38, Windows Security showed at least three identical sample-submission notifications.
• Seven minutes later, at 19:45, it showed at least five more.
• Opening the sample-submission dialog showed nine entries, all for the exact same path: %USERPROFILE%\.codex\config.toml.

This extends the original two-row example: the duplication can reach nine rows in one dialog, while repeated toast notifications are also generated in a short burst.

A read-only metadata check afterward found that the current file object's NTFS creation time and last-write time were both 19:50:50 KST, later than the two prompt bursts (size: 4,570 bytes; contents were not inspected). That is consistent with the file having been replaced/recreated at the same path after the prompts, but it does not establish which process did so or whether that caused the prompts.

The Defender Operational log for the surrounding window contained no warning/error or malware-detection event, and Get-MpThreatDetection returned no detection for that period. The visible UI was specifically the sample-submission consent dialog.

Environment

• Codex for Windows (MSIX): 26.707.9981.0 (x64)
• Windows 11 Pro 25H2: build 26200.8737 (x64)
• Microsoft Defender platform: 4.18.26060.3008
• Defender engine: 1.1.26060.3008
• Security intelligence: 1.455.125.0
• Real-time protection, behavior monitoring, IOAV protection, and tamper protection: enabled
• DisableRealtimeMonitoring = False
• MAPSReporting = 2
• SubmitSamplesConsent = 1 (SendSafeSamples)

I have not captured the hash/mtime at each individual prompt, so this still does not distinguish between repeated Codex writes, multiple Defender scan/submission requests, and a Windows Security UI/queue duplication issue.

Disabling Defender real-time or cloud protection is not a viable workaround for me; I want to keep the protection level enabled. I can provide redacted screenshots if useful.

I found a concrete Codex-side write path that may explain why Defender keeps reconsidering config.toml.

Installed build: Codex Desktop 26.715.4045.0 on Windows 11.

Inspection of the packaged Desktop JavaScript shows that it:

1. Generates a random Computer Use pipe name:

``text
\\.\pipe\codex-computer-use-${randomUUID()}
``

1. Places that transient value in SKY_CUA_NATIVE_PIPE_DIRECTORY.
2. Builds it into the managed mcp_servers.node_repl configuration.
3. Persists the result through config/batchWrite, which writes durable %USERPROFILE%\.codex\config.toml.

The random value is generated per Desktop process launch. Plugin/Node REPL reconciliation can also run more than once. Codex is therefore treating an ephemeral runtime endpoint as durable user configuration and can recreate or rewrite the file during otherwise normal app activity.

I cannot prove Defender’s internal sample-submission heuristic, but I can prove this Codex write path exists. On this machine:

• Defender recorded no threat for config.toml
• the Defender Operational log contained no matching detection
• a direct Defender scan of the file was clean
• choosing either Send or Don’t send did not prevent later prompts

The fix should be to keep SKY_CUA_NATIVE_PIPE_DIRECTORY in a process/session runtime overlay instead of writing it into config.toml. Managed reconciliation should also avoid rewriting the file when its durable semantic contents have not changed.

Same issue here. Defender keeps bugging me about config.toml every time I use Codex. OpenAI should definitely reach out to Microsoft about this if they haven't already. Seems like a false positive that needs to get sorted out.

I am also facing the same issue, as of 2026-08-01, the issue still exist.

Seeing the same thing here. Multiple config.toml submissions.

same here