[Bug]: Windows Desktop app fails to start: Codex app-server websocket closed (code=3221225495 / 0xC0000017) due to environment block overflow

What version of the Codex App are you using?

Microsoft Store / MSIX build 26.911.7940.0 (Codex CLI 0.141.0+)

What platform is your computer?

Windows 11 / Windows 10 x64

What issue are you seeing?

The desktop app fails immediately upon launch with the following error dialog:

ChatGPT failed to start.
(code=3221225495, signal=null).
Most recent error: Codex app-server websocket closed (code=3221225495)

Clicking "Check for Updates" results in net::ERR_BLOCKED_BY_CLIENT.

---

Root Cause Analysis (Reverse-Engineered from app.asar)

1. What 3221225495 Actually Means

Converting decimal 3221225495 to hex gives 0xC0000017.
In Windows NTSTATUS, this is STATUS_NO_MEMORY (ERROR_NOT_ENOUGH_QUOTA).
This is not an actual RAM exhaustion issue (the machine had 40 GB physical RAM with 20 GB free).

2. The Mechanism in Desktop Code

In oW / StdioConnection.spawnProcess() inside app.asar:

let r = {
  ...process.env,
  LOG_FORMAT: 'json',
  RUST_LOG: process.env.RUST_LOG ?? 'warn',
  CODEX_INTERNAL_ORIGINATOR_OVERRIDE: e.defaultOriginator ?? zU
};
// ...
let n = spawn(executablePath, args, {
  stdio: ['pipe', 'pipe', 'pipe'],
  env: sanitizedEnv,
  cwd: options.cwd
});

• When CreateProcessW / ZwCreateUserProcess is called on Windows inside the MSIX / AppContainer boundary, the kernel allocates memory for RTL_USER_PROCESS_PARAMETERS->Environment.
• On Windows NT, the serialized environment block buffer has an allocation quota limit of 32,767 characters (32 KB).
• When spawn() passes process.env down to codex.exe, if the serialized environment block exceeds 32 KB, the Windows kernel refuses to allocate the environment block, immediately failing process creation with NTSTATUS 0xC0000017 (3221225495).

3. Misleading UI Error

Because StdioConnection wraps process termination in a generic transport close handler, it prints:
Codex app-server websocket closed (code=3221225495)
even though the transport kind is stdio rather than websocket, leading users to mistakenly assume a network or proxy problem.

---

Real-World Case Study: How an Autonomous Agent Session Triggered This Bug

This issue occurred directly as a result of an autonomous development session driven by the agent:

1. Autonomous Execution Loop:
   The agent was autonomously running extensive test and verification loops during project development.
2. Ephemeral Directory Build Side Effects:
   Each test run created an isolated temporary directory via mkdtemp (e.g. AppData\Local\Temp\test-runner-<id>\dotnet-home) and invoked .NET SDK (dotnet build).
3. Registry Pollution:
   On Windows, the .NET SDK checks if %DOTNET_CLI_HOME%\.dotnet\tools exists in the persistent user environment and registers it into HKCU:\Environment\Path.
4. Self-Sabotaging Environment Bloat:
   Across 290+ autonomous test iterations, 291 unique temporary paths were permanently appended to the Windows registry, inflating the User PATH to 31,686 characters.
5. The Crash:
   Once the desktop app was closed and restarted, the environment block exceeded the 32 KB kernel limit, permanently bricking the desktop app until manual registry remediation was performed.

This reveals a critical need for environment isolation and guardrails during autonomous tool execution.

---

Workaround for Affected Users

Cleaning bloated User PATH immediately resolves the startup crash without losing any chat history or sessions:

# 1. Check if User PATH is bloated (>10,000 chars)
((Get-ItemProperty "HKCU:\Environment").Path).Length

# 2. Backup registry
reg export "HKCU\Environment" "$HOME\Environment_backup.reg" /y

# 3. Deduplicate and filter out stale/missing directories
$currentPath = (Get-ItemProperty "HKCU:\Environment").Path
$cleanEntries = ($currentPath -split ';' | Where-Object { 
    $_ -and (Test-Path $_ -ErrorAction SilentlyContinue)
}) | Select-Object -Unique
Set-ItemProperty -Path "HKCU:\Environment" -Name "Path" -Value ($cleanEntries -join ';')

# 4. Broadcast change (no reboot required)
Add-Type -Namespace Win32 -Name NativeMethods -MemberDefinition @"
[DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
public static extern IntPtr SendMessageTimeout(IntPtr hWnd, uint Msg, UIntPtr wParam, string lParam, uint fuFlags, uint uTimeout, out UIntPtr lpdwResult);
"@
[Win32.NativeMethods]::SendMessageTimeout([IntPtr]0xffff, 0x001A, [UIntPtr]::Zero, "Environment", 0x0002, 5000, [ref][UIntPtr]::Zero)

Once the User PATH was pruned from 31,686 chars to ~1,500 chars, ChatGPT.exe and codex.exe started cleanly without any issues.

---

Proposed Fix & Security Recommendations for Maintainers

1. Sanitize PATH before spawning codex.exe:
   In oW (where the sidecar environment dictionary is constructed), sanitize and deduplicate r.PATH on Windows, or prune non-existent folders so the environment block never exceeds 32 KB.
2. Environment Isolation for Agent Tool Execution:
   Autonomous agents running shell commands should have their environment modifications sandboxed to process-scope. Modifications to HKCU:\Environment or calls to setx by child processes during autonomous tasks should be blocked or isolated in a virtualized hive.
3. Accurate Error Reporting:
   • In StdioConnection, don't report "websocket closed" when the transport is stdio.
   • If process.platform === 'win32' and code === 3221225495 (0xC0000017), display a clear diagnostic message:
     "Failed to spawn backend engine due to environment block size limit (0xC0000017). Please ensure your PATH variable does not exceed 32,767 characters."

Locate the desktop app's StdioConnection.spawnProcess()/oW environment construction and the stdio close handler referenced in the report. First investigate Windows process spawning with an oversized environment, then determine the scope of the environment handling and diagnostic changes. Done means affected launches no longer fail silently and the error identifies the stdio/environment-limit cause.