Windows desktop app: Norton can block PowerShell after Codex activity

Screenshot evidence from Norton alerts:

1. Norton alert titled Threat secured: Norton blocked powershell.exe with detection IDP.HELU.PSE75 - Command line detection.
2. Norton alert titled Threat blocked: Norton blocked a .ps1 helper script with detection IDP.Generic and offered Move to Quarantine.

These screenshots support that the AV product is reacting both to the PowerShell command-line/process behavior and to script execution, not just to a single repository file path.

Norton AV clipboard output:
`Details

Threat name: IDP.HELU.PSE75%s_cmd
Threat type: Miscellaneous - This is malicious software that could harm your data, computer, or network.
Status: Repaired
Detected by: Behavioral Protection
On PC from: 09/09/2025, 21:37
Last Used: 09/09/2025, 21:37
Startup Item: Yes

Many users
Millions of users in the Norton Community have used this file.

Mature
This file was released 9 months ago.

High
The file risk is high.
____________________________

Activity

Path | Type | Status

____________________________

Details

Threat name: IDP.Generic
Threat type: Miscellaneous - This is an app that you may have unknowingly installed and that may harm your computer performance.
Status: Moved to Quarantine
Detected by: Behavioral Protection
On PC from: 31/05/2026, 15:31
Last Used: 31/05/2026, 16:11
Startup Item: No

Unknown
It is unknown how many users in the Norton Community have used this file.

Unknown
The file release is currently unknown

High
The file risk is high.
____________________________

Activity

Path | Type | Status`

Regression: ChatGPT 26.707.31428 triggers repeated Norton Behavioral Protection alerts in Codex mode on Windows

After ChatGPT updated from Microsoft Store on 2026-07-09, normal use of Codex mode began triggering high-severity Norton Behavioral Protection alerts. This did not happen with earlier versions of the app.

Environment:

• ChatGPT: 26.707.31428 (Microsoft Store, auto-updated)
• Windows: Windows 11 25H2, build 26200.8737
• Norton 360: 26.6.11052, build 26.6.11052.988
• Model: GPT-5.6

The impact is disruptive: Norton reports the related PowerShell processes as terminated and may quarantine temporary artifacts. The alerts appear during ordinary app use, not only while running a coding task. They occur consistently after opening Settings, have occurred during normal Codex conversations, and once occurred after application startup before any thread was opened or started.

The observation before any thread was opened makes repository code, project files, user prompts, and task execution unlikely causes. Process Monitor identifies ChatGPT.exe as the direct parent of the flagged PowerShell processes, which points to a desktop-host behavior rather than codex.exe or project code.

I have not tested Work mode. However, the observed helper appears to perform a UI-related icon operation independently of a coding task, so the same app-level behavior may also affect Work mode.

Norton detects:

IDP.HELU.PSE80%s_cmd
Detected by: Behavioral Protection

The detection occurs consistently after opening ChatGPT Settings. I also captured it during normal work in a Codex conversation, and once after application launch but before opening or starting any thread.

Process Monitor shows that the direct parent is ChatGPT.exe, not codex.exe:

ChatGPT.exe
  └─ powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -EncodedCommand <redacted>
       └─ conhost.exe 0xffffffff -ForceV1

Norton activity consistently reports four powershell.exe / conhost.exe pairs.

The decoded PowerShell payload appears to be a Codex-native icon helper:

• it references CODEX_NATIVE_DESKTOP_APP_ICON_PATH;
• it defines CodexShellIconNative;
• it uses shell32.dll, gdi32.dll, and user32.dll;
• it extracts an application icon and returns it as a PNG data URL.

I found no network request, persistence, registry modification, or deliberate file deletion in the captured payload. However, it combines -ExecutionPolicy Bypass, -EncodedCommand, dynamic C# compilation via Add-Type, and native DLL interop. This is a malware-associated command shape and is a plausible cause of Norton's heuristic detection.

A quarantined __PSScriptPolicyTest_*.ps1 contained only the standard PowerShell AppLocker lockdown-mode probe comment. It appears benign and may be collateral behavior from PowerShell startup rather than the direct PSE80 trigger.

Controlled attempts to reproduce the alert through normal project-file operations and small isolated PowerShell commands did not trigger Norton's Behavioral Protection. This suggests the issue is not caused by ordinary repository work or every PowerShell invocation, but by the ChatGPT/Codex host-specific command and execution context.

Could the application avoid -ExecutionPolicy Bypass and -EncodedCommand for this UI task, or move icon extraction into a signed native helper/API? The current behavior creates repeated high-severity Norton alerts during normal use.

Positive reproduction and remediation note for openai/codex#25425

Status: Reproducible on demand
Verified: 2026-07-10
Upstream issue: openai/codex#25425

Scope

This is deliberately not a restatement of the issue. The issue already establishes that Codex for Windows can trigger Norton detections around PowerShell. A later comment identifies the native-icon helper, decodes its payload, and reports that ordinary project operations and small PowerShell commands did not trigger Norton.

The useful additions below are:

1. a positive controlled reproduction using a behaviorally equivalent icon-extraction sequence;
2. independent verification that the helper is present in a different installed production build;
3. a direct native Electron replacement for the PowerShell helper.

New finding 1: positive controlled reproduction

Three tests were run while monitoring Norton Behavioral Protection:

| Test | Result | New Norton PSE80 event |
|---|---|---|
| Ordinary non-interactive Windows PowerShell command | Exit code 0 | No |
| Harmless Add-Type C# class returning an integer | Exit code 0 | No |
| Helper-equivalent icon extraction | Icon returned successfully; exit code 0 | Yes, immediately |

The reproducing test used the same relevant behavior as the installed helper:

powershell.exe
  -NoProfile
  -NonInteractive
  -ExecutionPolicy Bypass
  -EncodedCommand <UTF-16LE Base64 payload>

The payload:

• compiled C# at runtime with Add-Type;
• declared native calls into shell32.dll, user32.dll, and gdi32.dll;
• extracted the icon of the running packaged application;
• converted it to an in-memory PNG data URL;
• released the native icon handle.

The helper-equivalent test returned:

ICON_DATA_URL_OK length=1150
Child exit code: 0

Norton then recorded a new event:

| Field | Value |
|---|---|
| Detection | IDP.HELU.PSE80%s_cmd |
| Source | Behavioral Protection |
| Detected executable | powershell.exe |
| Alert ID | 81572140ab26 |
| Local time | 2026-07-10 19:17:56 |
| Detection ID | idpDetection_45eaac4c3e39cc789c61713a926fa14e1a4644f57f4af8a25ede9b394d18e3e0 |

Windows PowerShell was checked again after the event and remained executable with a valid Microsoft signature.

Interpretation

Neither PowerShell alone nor the simple dynamic C# control reproduced the alert. In this experiment, only the combined helper-equivalent sequence reproduced it: policy bypass, encoded script, runtime compilation, native API interop, icon extraction, and binary-to-Base64 conversion.

This is strong evidence that Norton is reacting to the helper's command shape, not to repository contents or ordinary Codex shell use.

The experiment does not establish which individual flag or operation is necessary or sufficient, and it does not exclude Norton using additional context such as parent-process reputation. It establishes the narrower claim that the benign helper behavior is sufficient to reproduce the same detection family on this environment.

New finding 2: the helper is present in another production build

Inspection of the installed app.asar for app version 26.707.3748.0 confirmed that the production code:

• starts the bare powershell.exe executable;
• supplies -NoProfile, -NonInteractive, -ExecutionPolicy Bypass, and -EncodedCommand;
• passes the target executable path through CODEX_NATIVE_DESKTOP_APP_ICON_PATH;
• uses the runtime-compiled class name CodexShellIconNative;
• starts the child process hidden;
• applies a 10-second timeout;
• catches failure and returns null when icon extraction fails.

That last behavior is important: icon extraction is already optional. A generic icon is therefore a safer fallback than launching an encoded PowerShell payload.

New finding 3: Electron already exposes a native replacement

Electron provides app.getFileIcon(), which returns the icon associated with a file path and supports icons embedded in Windows .exe, .dll, and .ico files.

The current helper can be replaced conceptually with:

const image = await app.getFileIcon(path, { size: "small" });
const dataUrl = image.toDataURL();

This removes all of the antivirus-sensitive elements at once: Windows PowerShell 5.1, policy bypass, encoded commands, Add-Type, temporary C# compiler processes, and hand-written P/Invoke declarations.

If a particular path cannot be handled by Electron, the application should return its existing generic icon or use a signed native helper. Icon fidelity should not take precedence over avoiding a malware-like execution chain.

Correlation data

| Component | Verified value |
|---|---|
| Package identity | OpenAI.Codex |
| Package version | 26.707.3748.0 |
| Package display name | ChatGPT |
| Norton 360 | 26.6.11052.1047 |
| Windows | 25H2, build 26200.8655 |
| Windows PowerShell | 5.1, executable 10.0.26100.8457, valid Microsoft signature |
| PowerShell 7 | 7.5.8, valid Microsoft signature |
| Bundled resources/codex.exe | Valid OpenAI Authenticode signature |

Requested action from OpenAI

1. Replace the PowerShell icon helper with Electron app.getFileIcon() or a signed native implementation.
2. Until the replacement ships, disable this optional helper or provide a remote kill switch and use the generic icon.
3. Add Windows regression tests asserting that icon rendering never spawns PowerShell or compiler processes.
4. Test the fixed flow with current Norton definitions and retain the positive-reproduction case as a regression test where possible.
5. Coordinate directly with Norton using the original payload, package artifacts, alert/detection IDs, and signing provenance. End users do not possess the complete release evidence and should not be responsible for vendor coordination.
6. Publish the first fixed app version and state whether Norton also supplied a definition or reputation update.

Safe interim guidance

Do not ask users to disable behavioral protection or broadly exclude PowerShell, %TEMP%, csc.exe, cvtres.exe, the Codex sandbox, or WindowsApps. Do not weaken the Codex sandbox. Those actions increase exposure and do not remove the malware-like command pattern from the application.

Acceptance criteria

The Norton issue is resolved when:

1. no icon-rendering path launches Windows PowerShell;
2. startup, Settings, and ordinary conversations do not spawn the encoded icon-helper command;
3. icons render through a native API or safely fall back to a generic icon;
4. Norton no longer records IDP.HELU.PSE80 during those flows with current definitions;
5. the fixed application version and any corresponding Norton update are documented publicly.

References

• OpenAI Codex issue #25425
• Electron app.getFileIcon() documentation
• OpenAI Windows sandbox documentation
• Norton false-positive submission guidance

Additional datapoint from Windows + Norton:

During a Codex update, Norton Behavioral Protection detected IDP.HELU.PSE80%s_cmd, terminated powershell.exe, csc.exe, cvtres.exe, and conhost.exe, and deleted several temporary PowerShell policy test files (__PSSCRIPTPOLICYTEST_*.ps1) and temporary DLLs.

After reboot, Windows entered Automatic Repair with "Your device ran into a problem and couldn't be repaired." Selecting Continue to Windows allowed the system to boot normally.

This appears correlated with the update and may help explain partially interrupted updates when AV software terminates PowerShell/.NET compilation processes.

Clarification to avoid conflating two related but distinct observations:

1. The original issue concerns Codex agent behaviour that triggers Norton Antivirus behavioural heuristics. In my case this occurred while a Frontend Agent was working on a Vite/React application. The agent appeared to be invoking PowerShell using patterns that resemble common malware techniques. As a workaround, I instructed agents to avoid using -EncodedCommand and -ExecutionPolicy Bypass and instead use transparent -File wrappers. Since doing so, I have not reproduced the original issue.

1. A recent Codex update also triggered Norton, but with a different heuristic (IDP.HELU.PSE80%s_cmd). I don't know whether this was caused by the update mechanism itself or by another PowerShell execution path used during the update process. The AV intervention terminated several PowerShell/.NET processes, after which the next reboot initially hung on a black screen before entering Windows Automatic Repair. Selecting "Continue to Windows" booted successfully.

I don't want to conflate these two observations. The update incident may or may not have a separate root cause. However, I think the original issue remains important: Codex agents should avoid invoking tools such as PowerShell in ways that unnecessarily resemble malware techniques and therefore trigger behavioural antivirus heuristics.

Regarding observation number 2 (IDP.HELU.PSE80%s_cmd), this issue occurs on my workstation almost every time I enable Planning Mode in Codex.

Norton 360 repeatedly flags PowerShell (IDP.HELU.PSE80%s_cmd) during normal Codex usage on Windows

Environment

• OS: Windows 11 Pro (fully updated)
• Codex: Latest Desktop version
• Antivirus: Norton 360 (Behavior Protection enabled)
• Workspace: Windows + WSL2 (Ubuntu)
• PowerShell: Windows PowerShell (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)

Description

While using the latest Codex Desktop application, Norton 360 repeatedly triggers Behavior Protection alerts.

The reported detection is:

IDP.HELU.PSE80%s_cmd

The alert references:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Earlier detections also quarantined temporary PowerShell files similar to:

__PSScriptPolicyTest_<random>.ps1

PowerShell itself is not removed from the system and continues to function normally.

Reliable reproduction

I can consistently reproduce the issue with the following steps:

1. Launch the Codex Desktop application.
2. Open any conversation.
3. Attach a simple .txt file.
4. Wait a few seconds.

Norton immediately raises a Behavior Protection alert.

The same detection also appears during other normal Codex operations, but attaching a .txt file reproduces it almost every time.

Observations

• The alerts only occur while Codex is running.
• I have never observed the alerts when Codex is completely closed.
• This started after updating to the latest Codex Desktop version.
• No suspicious system behavior has been observed.
• PowerShell continues to work correctly after the detection.
• This appears to be a false positive or an interaction between Codex and Norton's heuristic detection.

Norton detection details

Detection

IDP.HELU.PSE80%s_cmd

Protection

Behavior Protection

Risk

High

Depending on the event, Norton reports either Repaired or Quarantined.

Additional information

I found issue #25425 describing a similar problem involving Norton and PowerShell (PSE75). My case reports PSE80, and I can reliably reproduce it simply by attaching a .txt file inside Codex.

If helpful, I can provide:

• Norton screenshots
• Norton logs
• Exact timestamps
• Additional reproduction details

<img width="1125" height="717" alt="Image" src="https://github.com/user-attachments/assets/d814000d-bbfa-4265-88f6-45d8d0819358" />
<img width="1122" height="702" alt="Image" src="https://github.com/user-attachments/assets/e696ac6e-9af1-4635-ad44-bbd4fc509b4e" />