bug(codex/windows): Norton behavioral detection during hook execution; HTTP unavailable while MCP remains usable

[ordazm]

📝 Bug Description

On a native Windows host using the official Engram Codex integration, Norton reports IDP.HELU.PSE91 (command-line behavioral detection) and lists Windows PowerShell and Engram processes as terminated during Codex use.

Engram MCP memory operations remain usable, but the managed HTTP server used by lifecycle hooks is unavailable during subsequent inspection. This report describes observed behavior; it does not establish the exact detection trigger or attribute every server exit to Norton.

🔄 Steps to Reproduce

Observed workflow on the affected host; not independently reproduced on a clean machine:

1. Install the official Engram 2.2.1 Windows amd64 release.
2. Run engram setup codex with the official Codex plugin enabled.
3. Restart Codex and resume a session while Norton protection is enabled.
4. Inspect Norton history, Engram's HTTP startup log, and the availability of the default local HTTP port.

These steps were performed before this report. The latest investigation was passive: no hooks were manually executed, no processes were stopped, and no configuration was changed, to avoid disrupting ongoing Codex work.

✅ Expected Behavior

The supported integration should provide its HTTP-backed lifecycle functionality. Startup/backend failures should produce actionable diagnostics. A healthy MCP connection should not be mistaken for evidence that lifecycle hooks are healthy.

❌ Actual Behavior

• Norton reports termination of powershell.exe and engram.exe.
• MCP memory reads and writes succeed. Three engram.exe mcp --tools=agent processes were active during inspection; their multiplicity is not being reported as a bug.
• The HTTP startup log records listening events, but subsequent inspection finds no TCP listener on port 7437 and no persistent engram serve process.
• Previously collected engram doctor --json reports 9/9 checks OK. Those store checks do not establish HTTP or lifecycle-hook health.
• An Engram-executable-only behavioral exclusion did not restore HTTP availability and was removed. No broad antivirus exclusions are requested.

Operating System

Windows

Native Windows 11 Pro, x64, version 10.0.26200 (build 26200).

Engram Version

engram 2.2.1

Codex plugin version: 0.1.5.
Plugin marketplace checkout: 3692e1aff0f70a1ef41f0ce3ca7b9f54aad2dc68.

Agent / Client

Other

• Codex desktop package: 26.924.2738.0.
• App-server version reported earlier that day: 0.158.0-alpha.2.1.
• Windows PowerShell engine recorded in hook events: 5.1.26100.9549.
• NortonUI executable file/product version: 26.8.11125.1056 (not independently established as the detection-engine version).

📋 Relevant Logs

All times below are local, 2026-09-26, UTC-3.

08:11:25.251 — Windows PowerShell event 400 records the SessionStart launcher.
08:11        — Norton history reports IDP.HELU.PSE91.
               Activity lists powershell.exe and engram.exe as terminated.

2026/09/26 08:20:55 [engram] HTTP server listening on 127.0.0.1:7437
2026/09/26 08:25:12 [engram] HTTP server listening on 127.0.0.1:7437

Later passive inspection:
- Engram MCP processes remain active.
- No TCP listener on port 7437.

The Windows event exposes the official encoded PowerShell bootstrap dispatching run-bash-hook.ps1 with session-start.sh. The timing is correlated with the Norton incident at minute resolution; Norton's supplied activity report does not identify the exact blocked invocation or its PID.

💡 Additional Context

Artifact verification

• The downloaded engram_2.2.1_windows_amd64.zip SHA-256 matches the official release asset digest:
  c66947b2468d27104296fedb1bb8416f45fd880262606759217193a4bab9be0f.
• The installed executable matches the executable extracted from that verified release.
• Inspected hook definitions and dispatch/startup/helper scripts match the identified marketplace checkout after line-ending normalization.

These checks establish artifact provenance, not that the behavioral detection is necessarily a false positive.

Related work reviewed

Issue searches covered open and closed reports using Norton, the exact detection name, antivirus, GLOBALROOT, ownership mismatch, and Codex/Windows/server terms. No equivalent report was found in those searches.

• engram.exe virus? #45 and Descargar version de Windows 1.10.1 parece que da un falso positivo para Virus #93 concern older Windows antivirus/download detections.
• fix(codex): UserPromptSubmit hook times out on Windows (3s execution vs 2s timeout) #1271 concerns a Windows UserPromptSubmit timeout.
• bug(pi): stale pre-v2 server is reported as ownership mismatch after upgrade #1255 and Pi memory facade cannot resolve local server identity while MCP remains healthy #1269 concern Pi server identity/health behavior.
• PR fix(codex): restore Windows prompt and startup hooks (#1271) #1377 contains the encoded Windows launchers present in this checkout. This report does not establish that it introduced the Norton detection.

Investigation targets, not a proposed verified fix

Please investigate the Windows hook/server lifecycle and compatibility with Norton. Static inspection also identifies diagnostic limitations worth considering:

• The Windows wrappers can suppress exceptions with exit 0.
• The SessionStart health helper maps unreachable endpoints and instance mismatches to failure; the caller reports a generic ownership-mismatch message. That message was not captured as an observed runtime error in this incident.
• The real-session-context regression in codex_windows_hook_dispatcher_test.go uses an external HTTP fixture via ENGRAM_URL; it does not validate managed local server survival after the hook finishes.

The precise Norton-detected invocation and the cause of each HTTP server exit remain unknown. No clean-host reproduction, tested fix, or recommendation to disable antivirus protection is claimed. Any further reproduction should be isolated from ongoing user workloads.

Triage note: This report follows the current Bug Report fields. The submitting account cannot assign repository labels; please apply type:bug and status:needs-review. No implementation approval is assumed.

[dnlrsls]

Investigation update: an isolated native-Windows experiment reproduced the old launcher’s pipe-retention behavior, but did not reproduce the missing HTTP server. The lifecycle correction in #1538 addresses that separate mechanism; it does not establish the cause of the Norton detection.

Using source at 58d7029d1b1a50716c397ed49a377444c1f68add, we compared the current serve-background launch with the former Bash engram serve ... & launch shape, both using the current binary and official Windows hook dispatcher:

• Current launch: hook exit and stdout EOF at approximately 2.95 seconds; HTTP remained healthy afterward.
• Former launch shape: hook process exited at approximately 2.79 seconds, but stdout EOF remained blocked until the test-owned server was stopped. HTTP was still healthy more than 16 seconds after launch.

This was a single controlled run per launch shape, not an exact Engram 2.2.1 reproduction or a test of Codex enforcing its hook timeout. Norton was not tested. Temporary data, configuration homes and loopback ports were isolated, cloud autosync was disabled, and the owned processes and temporary files were cleaned up without changing the working tree.

The false-positive hypothesis remains unconfirmed. To establish causality, we still need the affected host’s detailed Norton event, including the blocked command, PID/parent process and termination action, correlated with the HTTP logs. If those records are unavailable, the next step is an isolated reproduction on a Norton-equipped host with protection enabled, not broad antivirus exclusions. This issue should remain open pending that evidence.