ERROR codex_core::tools::router: error=Exit code: -1073741502

Open 💬 2 comments Opened Apr 14, 2026 by sgotsko

What version of Codex CLI is running?

0.120.0

What subscription do you have?

ChatGPT Business

Which model were you using?

gpt-5.4-mini

What platform is your computer?

Microsoft Windows NT 10.0.19043.0 x64

What terminal emulator and version are you using (if applicable)?

PowerShell

What issue are you seeing?

The issue appears when executing Codex in SSH session, like through Jenkins or just SSH into machine and running codex in unelevated sandbox.

Codex response to any prompt that would require reading files from working directory:

I couldn’t analyze the current directory because command execution is failing at the environment level. Every attempt to run even minimal commands like dir, pwd, git status, or cmd /c dir exited immediately with code -1073741502 and no output."

The log file would have this line: ERROR codex_core::tools::router: error=Exit code: -1073741502
Investigatin this further it appears to be 0xC0000142 which is STATUS_DLL_INIT_FAILED

When running codex interactively it would ask to run commands with elevated permissions this is no go for me as I'm trying to wrap up everything in script.

--yolo does fix this issue but I have a security concerns with this method

config.toml

model = "gpt-5.4"
[projects.'C:\jenkins\workspace\MyProject']
trust_level = "trusted"

[windows]
sandbox = "unelevated"

The issue is specific to SSH session, when running it on the actural machine under same user it works fine.
I've compared the environments and haven't spotted anything that would point out to the issue.

Last known working version is 0.46.0

What steps can reproduce the bug?

Set up a Windows machine with Codex version above 0.46.0
Connect via SSH (any SSH client)
Navigate to a trusted project directory with workspace-write and trust_level = "trusted" in config
Run codex and ask anything that would require executing commands in the workdir, like "what's in this directory"
Observe Exit code: -1073741502 and escalation request

What is the expected behavior?

Unelevated sandbox should be able to spawn shell processes in SSH sessions

Additional information

Last known working version is 0.46.0
Removing .codex folder didn't help
Tried to downgrade version by version down to 0.115.0
Result same for interactive and codex exec variants of running codex

View original on GitHub ↗

2 Comments

benorhanuysal · 1 month ago

Additional reproducible non-interactive Windows service-session case:

Codex CLI: 0.144.0
OS: Windows Server 2025, build 26100, x64
Host context: a Windows service launched under a dedicated restricted service account
The service token, user profile, and required logon rights were verified
The official elevated sandbox setup completes successfully
A minimal elevated sandboxed PowerShell command fails with timed out after 15000ms connecting runner pipe-in
The same minimal command in the unelevated sandbox exits with 0xC0000142 (STATUS_DLL_INIT_FAILED)
Unelevated cmd.exe succeeds
PowerShell succeeds with danger-full-access
Re-running elevated setup and granting the documented logon rights did not change the result

This appears consistent with the SSH/Jenkins/non-interactive-session failure reported here, but reproduces from a real Windows service session on the current CLI. It narrows the failure to the sandbox runner / PowerShell startup path rather than the workspace or command itself.

The current Windows sandbox documentation lists Windows 11 as the recommended baseline and does not list Windows Server. Could a maintainer confirm whether Windows Server service sessions are supported? If supported, we can provide a redacted CODEX_HOME/.sandbox/sandbox.log, the exact command matrix, and relevant Windows event entries. If unsupported, documenting that boundary (and the supported unattended Windows host configuration) would help enterprise deployments.

wthong · 10 days ago

Adding a clean minimal repro that isolates the exact variable and confirms this is not SSH/service-session specific — it reproduces on a normal interactive local session too.

Codex CLI: 0.147.0 (PATH-resolved stable) and 0.148.0-alpha.9 (Codex Desktop bundled) — both 100% reproduce
OS: Windows 10 Education, build 19045, x64
Context: normal local interactive session (not SSH, not a service account)

Repro: run the identical command via codex exec with only --sandbox varying:

codex --sandbox danger-full-access exec --cd <repo> --skip-git-repo-check "pwsh.exe -Command \"Get-Content ...\""

→ exit 0, works normally.

codex --sandbox read-only exec --cd <repo> --skip-git-repo-check "pwsh.exe -Command \"Get-Content ...\""

or --sandbox workspace-write with the same command →

ERROR codex_core::tools::router: error=Exit code: -1073741502

(STATUS_DLL_INIT_FAILED / 0xC0000142)

Same for spawning node_repl.exe via an MCP tool call. All three binaries (pwsh.exe, node_repl.exe, and the one under test) run fine when invoked directly outside Codex's sandbox, so the binaries themselves are intact — this points at the Windows sandbox implementation itself, not the child process. No related crash events in Event Viewer in the relevant window, which is consistent with the DLL load being blocked at the token/job-object level rather than crashing normally.

This is currently blocking an automated CI-adjacent workflow that always runs Codex with --sandbox read-only for safety (a read-only code-review evaluator gated before every push). We've had to work around it locally by switching to --sandbox danger-full-access (the tool's own system prompt already enforces read-only intent at the instruction level, so this is an acceptable stopgap for us), but that removes the OS-level sandboxing that read-only/workspace-write are supposed to provide, which we'd like to restore once this is fixed upstream.

Happy to provide the full log or a smaller isolated repro script if useful.

---
Reported by Claude Sonnet 5 (Medium) on behalf of CareerOS engineering.