Desktop app renderer crashes on launch (render-process-gone, exit code -2147483645 / STATUS_BREAKPOINT) on Windows 11 24H2

Summary

Command Code Desktop (v0.1.35) will not open on Windows 11 24H2. The Electron main process starts fine and creates the window, but the sandboxed renderer process crashes immediately on every launch, so the window never becomes usable. The app looks like it is starting and then shows nothing.

Expected Behavior

The desktop app opens and shows a usable main window.

Actual Behavior

The main process starts and logs main.window-created and main.harness-loaded, then the renderer dies. The window never becomes usable.

%APPDATA%\Command Code\logs\main.log:

[2026-09-19 16:52:57.273] [info] Command Code starting - v0.1.35 (packaged: true)
[2026-09-19 16:52:57.537] [info] [startup] main.imports-start +1014ms (1014ms) -> main.module-loaded +13ms (1027ms) -> main.ready +65ms (1092ms) -> main.window-created +127ms (1219ms) -> main.harness-loaded +72ms (1291ms)
[2026-09-19 16:52:57.729] [error] [render-process-gone] crashed -2147483645
[2026-09-19 16:52:57.835] [error] [render-process-gone] crashed -2147483645

Exit code -2147483645 is 0x80000003 (STATUS_BREAKPOINT). Two render-process-gone events are logged per launch.

Steps to reproduce the issue

1. Install Command Code Desktop 0.1.35 (x64) on Windows 11 Pro 24H2 (build 26100), Intel Core i3-4150.
2. Launch the app from the Start Menu or Desktop shortcut.
3. Watch %APPDATA%\Command Code\logs\main.log - the window is created, then render-process-gone (crashed -2147483645) is logged twice.
4. The window never becomes usable.

Command Code Version

0.1.35 (desktop app) / 1.58.0 (cli)

Operating System

Windows

Terminal/IDE

Unknown

Shell

cmd.exe

Session file (optional)

No response

Fix prompt (optional)

Consider handling the case where the Windows renderer sandbox cannot initialize, instead of the renderer crashing with STATUS_BREAKPOINT. In resources/app/out/main/index.js the window is created with webPreferences.sandbox = true unconditionally; a fallback (or a documented opt-out) would let the app start on affected machines.

Additional context

Narrowed down on this machine:

• Not corrupted user data: launching with a fresh --user-data-dir crashes identically.
• Not GPU/driver: launching with --disable-gpu still crashes.
• Not forced ASLR/CFG: Windows Exploit Protection is at defaults (ForceRelocateImages NOTSET, CFG NOTSET), HVCI not running.
• Build is current: v0.1.35 is the latest desktop release.

Workaround that works: disabling the renderer sandbox. Both --no-sandbox and ELECTRON_DISABLE_SANDBOX=1 make the app start normally (reaches main.ready-to-show, zero crashes). The app hard-codes webPreferences.sandbox = true in resources/app/out/main/index.js.

Environment:

• Windows 11 Pro, build 26100 (24H2)
• CPU: Intel Core i3-4150 (Haswell, 2013) - not officially supported by Windows 11
• Command Code Desktop 0.1.35 (x64), Command Code CLI 1.58.0
• Windows Defender is the only AV product

Points to a Chromium renderer-sandbox incompatibility on this OS/CPU combination.

從 resources/app/out/main/index.js 開始，該檔案中 webPreferences.sandbox 會無條件啟用；檢查 renderer 視窗的設定以及 render-process-gone 的處理。在 Windows 11 24H2 上重現，並比較正常啟動與 --no-sandbox 或 ELECTRON_DISABLE_SANDBOX=1 的情況。完成的標準是：應用程式能夠進入可用的視窗且 renderer 不發生當機，同時保留適當的 sandbox，或記錄 opt-out。