›_ Codex Issues
Codex Issues / #27809

Windows app becomes unresponsive on launch with repeated VCPkgSrv.exe crashes

Open 💬 2 comments Opened Jun 12, 2026 by luyuan-cpp

Summary

Opening the Codex Windows app repeatedly triggers Windows "Close the program / Wait for the program to respond" unresponsive prompts. Rebooting the machine does not resolve it.

Environment

  • Codex Windows Store package: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
  • Codex app version reported by executable metadata: 149.0.7827.54
  • OS: Windows 11 Pro, version 10.0.26200, 64-bit
  • Shell/agent environment: Windows native PowerShell
  • Timezone/user locale during repro: Asia/Shanghai

Observed behavior

  • Starting Codex produces an unresponsive application prompt and the app remains slow/unresponsive for a long time.
  • This persists after reboot.
  • Around the same time, Windows Event Viewer shows repeated APPCRASH events for Visual Studio's VCPkgSrv.exe.
  • Many VCPkgSrv.exe processes remain running with very small working sets.

Relevant Windows Event Viewer details

Representative events from Application log on 2026-06-12 around 15:14-15:18 local time:

Provider: Application Error / Windows Error Reporting
Event: APPCRASH
Faulting application: VCPkgSrv.exe
Faulting application version: 18.0.11821.187
Faulting module: KERNELBASE.dll
Faulting module version: 10.0.26100.8655
Exception code: 0xe06d7363
Fault offset: 0x001659a4
Faulting application path: D:\Program Files\Microsoft Visual Studio\18\Enterprise\Common7\IDE\VC\vcpackages\x86\VCPkgSrv.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Bucket/hash: fc03d131108e965e77a3c8c5e9cfdb34

Codex logs observed locally

Recent app logs were present under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\06\12\

The latest log showed repeated git-origin watcher activity and app-server routing, plus messages like:

[electron-message-handler] Received turn/completed for unknown conversation
[electron-message-handler] Item not found in turn state

No obvious direct network/login failure was visible in the small tail inspected.

Notes

This may be an interaction between Codex launch/project scanning and Visual Studio's VC package service (VCPkgSrv.exe), rather than a direct Codex process crash. Please let me know if additional logs or a safer diagnostic bundle would help.

View original on GitHub ↗

2 Comments

luyuan-cpp · 2 months ago

Additional repro after reboot / restart attempt.

The user restarted and reported that Codex still took a very long time to become usable again. A 30-minute local diagnostic sampler was running from 2026-06-12 15:35:56 to 16:05:58 Asia/Shanghai.

Diagnostic window

  • Diagnostic run: 2026-06-12 15:35:56 -> 2026-06-12 16:05:58 local time
  • Codex package: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
  • OS: Windows 11 Pro 10.0.26200, 64-bit
  • OS boot time for this run: 2026-06-12 14:49:22

Process sampling summary

Sampled every 5 seconds for 30 minutes:

Codex samples:    2963 across 10 unique Codex PIDs
vcpkgsrv samples: 8018 across 88 unique VCPkgSrv PIDs
First sample:     2026-06-12T15:35:58+08:00
Last sample:      2026-06-12T16:05:52+08:00

This suggests many short-lived/restarted VCPkgSrv.exe instances during the period where the app was difficult to use.

New Windows Event Viewer findings

The earlier report showed VCPkgSrv.exe crashing in KERNELBASE.dll. This later run also shows repeated VCPkgSrv.exe crashes in cpfe.dll:

TimeCreated: 2026/6/12 15:55:23 and 15:55:27
Provider: Application Error
Faulting application: VCPkgSrv.exe
Faulting application version: 18.0.11821.187
Faulting module: cpfe.dll
Faulting module version: 23.0.11821.187
Exception code: 0xc0000005
Fault offsets: 0x00451166, 0x00440481
Faulting application path: D:\Program Files\Microsoft Visual Studio\18\Enterprise\Common7\IDE\VC\vcpackages\x86\VCPkgSrv.exe
Faulting module path: D:\Program Files\Microsoft Visual Studio\18\Enterprise\Common7\IDE\VC\vcpackages\x86\cpfe.dll
Report IDs: 4be07c1a-be3c-4496-8063-c8655f14213c, df782268-c913-48fb-a02c-c88c591278a2
WER hashes: 5d0575b3299e633b5c79451fece6c9b9, 07571b28c0e258effc2f1fc7d681b882

Other crash observed in the same window

A local project helper named McpRegister.exe also crashed at 2026/6/12 15:56:14:

Application: McpRegister.exe
.NET Version: 8.0.27
Exception: System.IO.DirectoryNotFoundException
Missing path: C:\Users\Administrator\.workbuddy\mcp.json
Faulting module: KERNELBASE.dll
Exception code: 0xe0434352
Report ID: 04a1d015-a37c-4fe5-9b6e-2a0f8e46fbb7

I am including this because it happened during the same startup/recovery window and may indicate Codex was running project/tooling discovery or MCP-related setup that triggered local helpers. It may be unrelated to the VCPkgSrv.exe loop, but it is another reproducible startup-time failure.

Codex app log tail highlights

Recent Codex log tails during/around startup contained repeated app-server routing and plugin/app list calls, plus entries such as:

Statsig: error while bootstrapping post-login client ... Timed out while fetching post-login Statsig bootstrap
Statsig: error while bootstrapping post-login client ... user.custom.workspace_type ... expected string/number/boolean/array/undefined, received null
Request failed ... method=fs/readFile ... os error 3
[electron-fetch-handler] codex-home request ... origin events include render-process-gone / unresponsive handlers

Raw logs were not attached here to avoid sharing project/session content, but the local diagnostic output was retained on the user's machine.

luyuan-cpp · 2 months ago

Additional repro after another reboot, now on a newer Codex Windows package.

Diagnostic window

  • User rebooted again and reported slow startup / long wait before Codex became usable.
  • Current local time when inspected: 2026-06-17 09:23:33 +08:00
  • OS boot time: 2026-06-17 09:08:00 +08:00
  • Codex app started around 2026-06-17 09:09:09 +08:00
  • Codex package has updated since the original report:
  • Previous package in earlier report: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
  • Current package: OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0

Current process state after reboot

At 2026-06-17 09:23 +08:00, Codex was running and two VCPkgSrv.exe processes were present:

Codex process count: 9
Codex total working set: ~1054.7 MB
Codex total CPU time: ~98.84 s

VCPkgSrv process count: 2
VCPkgSrv total working set: ~1912.7 MB
VCPkgSrv total CPU time: ~9.73 s

VCPkgSrv PID 15592: started 2026/6/17 09:19:52, working set ~1461.7 MB
VCPkgSrv PID 22860: started 2026/6/17 09:20:15, working set ~451.0 MB
VCPkgSrv path: D:\Program Files\Microsoft Visual Studio\18\Enterprise\Common7\IDE\VC\vcpackages\x86\VCPkgSrv.exe

This is notable because previous reports showed repeated VCPkgSrv.exe APPCRASH events; this latest reboot did not immediately produce a new APPCRASH in Event Viewer, but still produced large resident VCPkgSrv.exe processes shortly after Codex startup.

Windows Event Viewer / WER check

For the last day, Application log did not show a fresh VCPkgSrv.exe APPCRASH after the 2026-06-17 reboot. The newest matching WER archive entries were older:

AppCrash_VCPkgSrv.exe ... LastWriteTime 2026/6/15 17:39:33
AppCrash_VCPkgSrv.exe ... LastWriteTime 2026/6/15 16:51:00
Older VCPkgSrv / McpRegister crash archives from 2026/6/12 remain present.

There were unrelated Windows Store update/download failures on 2026/6/16 19:37-19:38 and a Visual Studio nonfatal error on 2026/6/16 14:30, but no fresh Codex/VCPkgSrv APPCRASH event in the inspected reboot window.

Codex log highlights from 2026-06-17 startup

Relevant local log directory:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\06\17\

The startup logs show repeated git-origin scans, plugin/app/model/status calls, and some slow calls/errors:

2026-06-17T01:02:09.568Z ... method=mcpServerStatus/list durationMs=4960
2026-06-17T01:02:11.044Z error [electron-fetch-handler] Failed to list child processes ... powershell.exe ... Get-CimInstance Win32_Process ...
2026-06-17T01:02:13.325Z ... method=app/list durationMs=8734
2026-06-17T01:05:06.062Z error [electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
2026-06-17T01:07:15.125Z error [electron-fetch-handler] Failed to list child processes errorCode=3221225794 ... Get-CimInstance Win32_Process ...
2026-06-17T01:11:00.579Z ... method=mcpServerStatus/list durationMs=4088

Summary

After updating to 26.609.9530.0 and rebooting, the user still experiences slow startup / long wait. The new data point is not a fresh crash signature, but high-memory VCPkgSrv.exe processes appearing after Codex startup and Codex logs showing slow MCP status/app list calls plus failures when listing child processes through PowerShell/CIM.