Codex Desktop (Windows): bundled pwsh.exe invocations blocked at startup by Defender/AMSI (HackTool:PowerShell/ApexToolkit.A); matched content unknown

Affected surface: Codex Desktop on Windows (session originator codex_work_desktop, source vscode), using its bundled PowerShell 7 runtime (pwsh.exe).

Incident date: September 17, 2026. Local times are EDT (UTC−04:00).

Versions (with evidence source):

• Internal Codex CLI/harness version: 0.154.0-alpha.6.2 (source: Codex session metadata).
• Codex Desktop app version: unknown (not present in available evidence).
• Bundled pwsh.exe: 7.6.5.500 (supplied, not independently verified).
• Windows 11; Microsoft Defender with AMSI active.

Summary. On September 17, 2026, two pwsh.exe -Command … invocations launched by Codex Desktop failed at startup with a Windows Defender/AMSI block. The displayed error is anchored at line 1 of a startup-prologue fragment, not at the requested command or its target script.

Anonymized launch excerpts (usernames/paths/script names replaced with placeholders):

• ["<…>\pwsh.exe","-Command","./scripts/Sample.ps1"] → failed, exit 1
• ["<…>\pwsh.exe","-Command","Get-Content -LiteralPath './scripts/Sample.ps1'"] → failed, exit 1

Abridged error excerpt (verbatim, shortened):
ParserError:
Line |
1 | try { [Console]::OutputEncoding=[System.Text.Encoding]::UTF8 } catch .
| This script contains malicious content and has been blocked by your antivirus software.

Observations.

• The error displays a startup-prologue fragment (try { [Console]::OutputEncoding=… } catch …) that is not part of the requested command or the target script (whose first line is #requires -Version 7.2). Its origin, and the complete wrapper's contents, were not recovered from the records inspected — see questions below.
• A read-only Get-Content invocation failed identically, so the block is not specific to executing the target script.
• Startup parse failure is observed; target-script non-execution is strongly inferred. The content AMSI actually matched is unknown — only the prologue fragment appears in the error; the complete wrapper and the scanned buffer were not recovered from the records inspected.

Supplied Defender/signature context (reported, not independently verified):

• Detection: HackTool:PowerShell/ApexToolkit.A, source AMSI.
• Detection times (EDT, UTC−04:00): 12:41:22, 12:42:06, 12:42:14 PM (= 16:41:22, 16:42:06, 16:42:14 UTC) on September 17, 2026. The first two align to the two invocations above; the third has no matching invocation in the inspected records.
• The bundled pwsh.exe reportedly carries a valid Microsoft Corporation signature (v7.6.5.500). A valid executable signature attests to the interpreter binary only; it does not establish that the submitted script/command content was benign. These are separate questions.

Questions for OpenAI.

1. Does Codex Desktop prepend a startup prologue/wrapper to bundled-pwsh.exe -Command invocations, and if so, what are its complete contents?
2. Is that wrapper submitted to AMSI as a single buffer together with the user command?
3. Can Codex retain the full submitted buffer to aid diagnosis of AV/AMSI blocks?

Scope note. This report concerns these Codex Desktop startup failures.

Start at the bundled pwsh.exe -Command launch path used by Codex Desktop, then trace how the startup prologue is assembled and submitted to AMSI. Determine whether the complete wrapper and user command share one buffer and whether that buffer can be retained. Done means the wrapper origin, AMSI submission behavior, and diagnostic-retention options are documented.