Windows desktop freezes after updates: a verified workaround for missing cua_node runtime caches

[FateW99]

Sharing a local recovery method for the failure tracked in #49611. My earlier report, #50256, was closed as a duplicate. This is a user-tested workaround, not an official fix.

When this may apply

After a desktop update, switching windows, opening Settings, navigating chats or typing can trigger severe freezes. On the affected machine, the desktop log repeatedly recorded bundled_executable_relocation_failed with operation=rename_staging and errorCode=EPERM for the bundled Node runtime.

The complete cua_node cache required by the installed build was missing. Older cache generations and failed staging directories were present. Read-only inspection of the installed client showed synchronous copying and directory renaming in this preparation path, consistent with the observed UI stalls.

What restored responsiveness

The replacement files came from the already-installed official application package. No runtime download or app reinstall was needed.

1. Identify the exact running app package and its bundled app/resources/cua_node directory.
2. Determine the runtime cache ID expected by that installed build from its resolver or failure destination. The ID is build-specific; do not substitute an older cache or guess it from the app version string.
3. Outside the desktop main process, copy the complete bundled runtime tree into separate staging under the actual runtime-cache root. The default logical root is %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node; account for any existing directory junction.
4. Verify every copied file against the installed source using file size and SHA-256, then publish the verified tree under the expected cache ID. Preserve working caches; do not blindly overwrite an existing destination.
5. Resume ordinary use and check that the same relocation failures stop.

The application installation, conversations, authentication, configuration and security settings were left unchanged. In this case the running app recovered without restarting.

Latest result and limitations

This recurred on October 21, 2026 with desktop package 26.1016.6573.0. The initial check found 37 relocation failures in the current main-process log. After preparing the matching runtime, all 2,384 files (252,751,033 bytes) matched the installed originals.

During approximately the first minute afterward, no new relocation failures appeared, the runtime helper became ready, and the user confirmed that responsiveness had improved. One main-thread-jank record remained, so this does not establish that every UI delay disappeared.

The underlying Windows reason for EPERM is still unknown. The affected setup includes a cache-directory junction, but its involvement has not been established. This method is only relevant when the matching runtime is missing or incomplete and the same error signature is present; it is not a general cure for all Windows freezes. Another update can require a new cache generation and expose the problem again.

A supported runtime-repair operation, preparation outside the UI thread, and bounded failure retries would help avoid repeated manual recovery.