Windows: SecureLink process injection crashes Codex App host with 0xC0000005

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

• #33981

Powered by Codex Action

Thanks. I reviewed #33981. The symptom overlaps, but this is not a confirmed duplicate: #33981 does not identify an injected module or a confirmed remediation, while #34107 captured SecureLink 3.8.5 loading WsInjtdll64.dll and WsInjProctDll64.dll through WsInjCoreDrv.

After uninstalling SecureLink with its vendor uninstaller and rebooting, the service, driver, and injected modules were gone, and Codex App remained stable with no new crash event or Crashpad dump. I am therefore leaving this issue open as a confirmed SecureLink-specific compatibility case unless maintainers determine that it should be consolidated.

Same crash here — thank you for the detailed write-up, it matches exactly what I've been
chasing. I'm hitting the identical failure on the same app build, just triggered by a
different third-party security agent, so I wanted to add my data point to confirm this
isn't specific to one tool.

---

Second confirmed injector — same class of bug, different vendor

On my corporate-managed PC the crash is caused by a different kernel-mode
endpoint-security agent injecting into ChatGPT.exe, which suggests this is a general
third-party-DLL-injection class bug rather than a single-vendor issue.

Environment

• Codex App OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0 (same build as OP)
• Windows 11 Enterprise, 10.0.26200, x64
• Injector: a kernel-mode enterprise DLP / document-security agent (mandated, cannot be

uninstalled by the user). Injection originates from a kernel driver, so it maps hook
DLLs into every GUI process regardless of user-mode settings.

Symptom / variant

• App launches, window shows, then the process self-terminates. Exit code

0xC0000417 (STATUS_INVALID_CRUNTIME_PARAMETER) — a __fastfail; a variant of OP's
0xC0000005, but the same "injected DLL is incompatible with the Chromium host" failure
mode. No shutdown log, no crashpad report.

• The log always cuts off immediately after the in-app browser (IAB) starts:

So this also overlaps #30178 (in-app browser crashes the main app).

• Multiple non-Microsoft, non-Store-signed hook DLLs from several third-party security

vendors are mapped into ChatGPT.exe at runtime (vendor names withheld).

Decisive evidence pointing at the actual fix: Claude blocks the same injection and survives

On the same machine, the Claude desktop app (also Electron/Chromium) does not crash.
Windows CodeIntegrity Event 3033 shows claude.exe repeatedly blocking the injected
third-party hook DLL ("did not meet the Microsoft signing level requirements") — i.e. Claude's
renderer/child processes run with RendererCodeIntegrity (MicrosoftSignedOnly + AllowStore),
so the injected DLL never loads and there is no crash.

For ChatGPT.exe there are zero such 3033 block events → the in-app browser process is
not running that signature policy → the DLL loads → fast-fail.

Why external remediation isn't viable here

The enterprise DLP agent cannot be uninstalled by the user (unlike OP's case). An external
mitigation doesn't work either: applying
Set-ProcessMitigation -Name ChatGPT.exe -Enable MicrosoftSignedOnly,AllowStoreSignedBinaries
via IFEO is keyed by image name, so it also hits the main process (which legitimately loads
non-MS DLLs, e.g. GPU) and breaks startup with an error dialog. The policy can only be applied
selectively to the renderer/browser child processes, which only the app itself can do.

Request

Please enable RendererCodeIntegrity (block non-Microsoft/non-Store binaries) on the in-app
browser / IAB child process, exactly as the Claude desktop app already does. That would make
Codex App resilient to third-party DLL injection in enterprise DLP environments, where the app
is otherwise unusable and the security agent cannot be removed. This likely also resolves #30178.

Thanks so much. Finally I found a way to successfully fixed my codex.