[Windows] 26.901.1978.0 fails to launch UI when cua_node staging cannot copy node_repl.exe

Summary

After updating the Microsoft Store Codex Windows app to 26.901.1978.0, Codex launched several ChatGPT.exe processes but never created a visible window. All processes were responsive, but MainWindowHandle remained 0.

Investigation showed that the new bundled cua_node runtime repeatedly failed during staging. Each launch created a new incomplete .staging-ad3b5049246cde44-* directory. The incomplete staging directories contained node.exe but were consistently missing node_repl.exe.

Manually staging the current package's app\resources\cua_node using xcopy /G into the expected versioned runtime directory fixed the problem immediately. Codex then launched normally.

This appears to be another manifestation of the EFS / Application Protected WindowsApps relocation issue reported in #32732 and #25220, but in this build the failure blocks the entire Codex UI from appearing.

Environment

Codex package: OpenAI.Codex_26.901.1978.0_x64__2p2nqsd0c76g0
Platform: Windows x64
Install type: Microsoft Store / MSIX
Runtime root: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Symptoms

Immediately after attempting to launch Codex:

Id    ProcessName  Responding  MainWindowHandle
2396  ChatGPT      True        0
25444 ChatGPT      True        0
33412 ChatGPT      True        0
33576 ChatGPT      True        0
35452 ChatGPT      True        0

The startup log stopped after:

2026-09-03T09:31:33.374Z info [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
2026-09-03T09:31:33.375Z info Launching app agentRunId=null allowDebugMenu=false allowDevtools=false allowInspectElement=false buildFlavor=prod enableSparkle=false enableUpdater=true nodeEnv=undefined packaged=true platform=win32
2026-09-03T09:31:33.581Z info Appshot hotkey inactive configured=true enabled=false platform=win32

No main window appeared.

Runtime staging evidence

The runtime directory contained three failed staging attempts plus an older complete runtime:

Name                              Files  NodeExe  NodeRepl
.staging-ad3b5049246cde44-VWwnnl  2542   True     False
.staging-ad3b5049246cde44-xBEXDT  3052   True     False
.staging-ad3b5049246cde44-YJEcC5  2119   True     False
415ffebf3d576e9b                  4679   True     True

After deleting the failed staging directories and launching Codex again, a new failed directory immediately appeared:

.staging-ad3b5049246cde44-co8bps
415ffebf3d576e9b

This confirms the current build expected runtime hash ad3b5049246cde44 and repeatedly failed to finish materializing it.

PowerShell Remove-Item -Recurse -Force also failed while traversing very deep paths under the incomplete staging trees, e.g. node_modules\@oai\sky\dist\js-dependency-cache\...\pnpm-store\..., requiring long-path-aware removal.

Workaround that fixed the launch

With all ChatGPT.exe processes stopped, the current package runtime was copied manually:

$pkg = Get-AppxPackage OpenAI.Codex
$src = Join-Path $pkg.InstallLocation "app\resources\cua_node"
$dst = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\ad3b5049246cde44"

New-Item -ItemType Directory -Force -Path $dst | Out-Null
cmd /c xcopy "$src\*" "$dst\" /E /I /H /Y /G

Verification after the copy:

Test-Path "$dst\bin\node.exe"       => True
Test-Path "$dst\bin\node_repl.exe"  => True
File count                            => 4683

After this, Codex launched successfully and the UI appeared normally.

Expected behavior

Codex should successfully materialize the bundled cua_node runtime from the protected Microsoft Store package during an update, without requiring manual copying.

If normal copy semantics fail for Application Protected/EFS resources, the Windows relocation implementation should use an equivalent of COPY_FILE_ALLOW_DECRYPTED_DESTINATION (the behavior that makes xcopy /G work), or another supported stream-copy mechanism.

The app should also detect an incomplete staging runtime and surface the underlying relocation error instead of leaving several responsive background processes with no UI.

Why this is particularly disruptive

The runtime hash changes when Codex updates. Therefore, a previously complete runtime such as 415ffebf3d576e9b does not prevent the problem when a newer build expects ad3b5049246cde44. If the protected-file relocation bug persists, the failure can recur on every update that introduces a new cua_node runtime.

[Windows] Codex 26.707 cannot stage Browser runtime from EFS-protected WindowsApps files #32732 — Windows Codex cannot stage Browser runtime from EFS-protected WindowsApps files
[Windows] Bundled plugins (Computer Use, Browser, Chrome, LaTeX) unavailable — copyfile fails on EFS-encrypted WindowsApps files #25220 — bundled plugin copyfile failures on EFS-encrypted WindowsApps files
[Windows][WSL] MSIX EFS-encrypted bundled codex fails relocation with ERROR_ENCRYPTION_FAILED (0x80071770) #38696 — related MSIX EFS relocation failure for WSL executables

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Bug report: ChatGPT/Codex Desktop repeatedly fails to start on Windows after auto-update due to cua_node runtime relocation #42412
Windows Codex Desktop repeatedly regresses across updates due to Application Protected runtime relocation failures #41654
[Windows][26.825.5331.0] Headless startup caused by Application Protected node_repl.exe relocation failure (0x80071770) #41540
[Windows][26.825.6671.0] Headless startup persists after clean runtime reset; cua_node staging never finalizes #41850

Powered by Codex Action

Confirmed on a newer Windows build: OpenAI.Codex 26.901.2854.0 (Microsoft Store/MSIX, x64).

Observed startup state matched this issue:

several ChatGPT.exe processes started;
MainWindowHandle = 0 for all of them;
main / crashpad / GPU / network / storage processes present;
no ChatGPT.exe --type=renderer;
no codex.exe ... app-server;
no visible UI.

Runtime staging evidence under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node:

repeated .staging-8e7585fc8f35ed57-* directories created on launch;
bin\node.exe present;
bin\node_repl.exe missing;
manifest.json missing;
packaged source at app\resources\cua_node\bin\node_repl.exe exists.

The same workaround fixed the app immediately:

stop all ChatGPT.exe / codex.exe processes;
create the final runtime directory %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\8e7585fc8f35ed57;
copy the complete packaged app\resources\cua_node tree with xcopy /E /I /H /Y /G;
verify bin\node.exe, bin\node_repl.exe, and manifest.json all exist.

Result: 4683 files copied, and Codex opened normally on the next launch.

This confirms the protected-file/runtime relocation bug still reproduces in 26.901.2854.0, with a new runtime hash, and that the xcopy /G full-runtime workaround remains effective.

Well done！

I can confirm that this issue still reproduces on a newer Codex Windows build:

Codex version: 26.901.2854.0
Install type: Microsoft Store / MSIX
Platform: Windows x64
Package status: Ok

Symptoms were the same: multiple ChatGPT.exe processes were running, but no visible Codex window appeared.

I checked:

Get-Process ChatGPT -ErrorAction SilentlyContinue |
    Select Id, ProcessName, Responding, MainWindowHandle, MainWindowTitle, Path

The app process was alive, but no main window was created.

I then inspected:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

There were many failed staging directories:

.staging-8e7585fc8f35ed57-rsAX9n
.staging-8e7585fc8f35ed57-rCN2Sp
.staging-8e7585fc8f35ed57-2l7wnh
...

All of them showed the same incomplete state:

NodeExe  = True
NodeRepl = False
Manifest = False

So the runtime staging process was repeatedly failing before finalization.

I manually copied the bundled runtime from:

<OpenAI.Codex package>\app\resources\cua_node

to:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\8e7585fc8f35ed57

using:

& xcopy.exe "$src\*" "$dst\" /E /I /H /Y /G

The copy completed successfully with:

4683 files copied

Afterwards, verification showed:

NodeExe  = True
NodeRepl = True
Manifest = True

Codex immediately launched normally after this.

So this appears to still affect build 26.901.2854.0, and the xcopy /G workaround remains effective.

I can confirm that this issue is still reproducible on a newer Windows build:

Codex Desktop: 26.901.4073.0

In my case, the app started multiple background ChatGPT.exe processes, but no desktop window was created. MainWindowHandle remained 0.

The active CUA runtime was:

Runtime ID: c2900163265bdaec

Source:
C:\Program Files\WindowsApps\OpenAI.Codex_26.901.4073.0_x64__2p2nqsd0c76g0\app\resources\cua_node

Failed staging directory:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-c2900163265bdaec-*

Expected final runtime:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\c2900163265bdaec

What I found

The problem still appears to be related to incomplete cua_node runtime materialization from the protected WindowsApps package.

However, I ran into an additional problem with the existing workarounds.

Using:

xcopy /E /I /H /Y /G

to copy the complete runtime was not reliable on my machine. The copy could stop before the complete runtime had been materialized.

I then tried implementing a per-file copy using PowerShell, but:

Get-ChildItem -Recurse

also failed while traversing the bundled pnpm dependency tree.

For example, it failed under a path similar to:

cua_node\bin\node_modules\@oai\sky\dist\js-dependency-cache\
shared-v1\applied-bk-agent-openai-js\pnpm-store\v11\links\
@rollup\plugin-typescript\12.1.2\...

with DirectoryNotFoundException.

This appears to be a second Windows-specific problem caused by the extremely deep pnpm directory structure / long paths.

Workaround that worked for me

The reliable solution was:

use robocopy /L only to enumerate the complete runtime tree, since it handles long paths better than Get-ChildItem -Recurse;
copy each file individually;
use the \\?\ extended-length path prefix;
read the packaged file with .NET File.Open;
create a new destination file with .NET File.Open(... FileMode.Create ...).

This avoids both the long-path traversal problem and the protected/encrypted file-copy behavior.

Here is the PowerShell script that successfully restored the runtime for me:

$ErrorActionPreference = "Stop"

# Stop Codex / ChatGPT Desktop
Get-Process ChatGPT -ErrorAction SilentlyContinue |
    Stop-Process -Force

Start-Sleep -Seconds 1


# Locate the currently installed Codex package
$pkg = Get-AppxPackage OpenAI.Codex |
    Sort-Object Version -Descending |
    Select-Object -First 1

if (-not $pkg) {
    throw "OpenAI.Codex package not found."
}

$src = Join-Path $pkg.InstallLocation "app\resources\cua_node"

$runtimeRoot =
    "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node"

Write-Host ""
Write-Host "Codex version : $($pkg.Version)"
Write-Host "Source        : $src"


# Detect the runtime ID from the newest failed staging directory
$staging = Get-ChildItem `
    -LiteralPath $runtimeRoot `
    -Directory -Force |
    Where-Object { $_.Name -like ".staging-*" } |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

if (-not $staging) {
    throw "No staging directory found."
}

if ($staging.Name -notmatch '^\.staging-([0-9a-fA-F]+)-') {
    throw "Could not parse runtime ID."
}

$runtimeId = $Matches[1]
$dst = Join-Path $runtimeRoot $runtimeId

Write-Host "Staging       : $($staging.Name)"
Write-Host "Runtime ID    : $runtimeId"
Write-Host "Destination   : $dst"
Write-Host ""

New-Item -ItemType Directory -Force -Path $dst |
    Out-Null


# Enumerate the source runtime using robocopy.
# /L means LIST ONLY; robocopy does not actually perform the copy.
Write-Host "Enumerating source runtime with robocopy..."

$raw = & robocopy `
    $src `
    $dst `
    /L /E /FP /NJH /NJS /NDL /NC /NS /R:0 /W:0

$files = @(
    $raw |
    ForEach-Object {
        $_.Trim()
    } |
    Where-Object {
        $_ -and
        $_.StartsWith(
            $src,
            [System.StringComparison]::OrdinalIgnoreCase
        )
    }
)

Write-Host "Files found    : $($files.Count)"
Write-Host ""

if ($files.Count -eq 0) {
    throw "Robocopy did not return any source files."
}


# Convert normal Windows paths to extended-length paths.
function Get-LongPath {
    param(
        [Parameter(Mandatory=$true)]
        [string]$Path
    )

    if ($Path.StartsWith("\\?\")) {
        return $Path
    }

    if ($Path.StartsWith("\\")) {
        return "\\?\UNC\" + $Path.Substring(2)
    }

    return "\\?\" + $Path
}


# Materialize the runtime one file at a time.
$failed = New-Object System.Collections.Generic.List[object]

$i = 0
$total = $files.Count

foreach ($sourceFile in $files) {

    $i++

    $relative =
        $sourceFile.Substring($src.Length).TrimStart("\")

    $targetFile =
        Join-Path $dst $relative

    $sourceLong =
        Get-LongPath $sourceFile

    $targetLong =
        Get-LongPath $targetFile

    $targetDir =
        [System.IO.Path]::GetDirectoryName($targetLong)

    try {

        if (-not [System.IO.Directory]::Exists($targetDir)) {

            [System.IO.Directory]::CreateDirectory($targetDir) |
                Out-Null
        }

    }
    catch {

        $failed.Add(
            [PSCustomObject]@{
                File  = $relative
                Stage = "mkdir"
                Error = $_.Exception.Message
            }
        )

        continue
    }


    $success = $false

    for (
        $attempt = 1;
        $attempt -le 3 -and -not $success;
        $attempt++
    ) {

        $inputStream = $null
        $outputStream = $null

        try {

            $inputStream =
                [System.IO.File]::Open(
                    $sourceLong,
                    [System.IO.FileMode]::Open,
                    [System.IO.FileAccess]::Read,
                    [System.IO.FileShare]::Read
                )

            $outputStream =
                [System.IO.File]::Open(
                    $targetLong,
                    [System.IO.FileMode]::Create,
                    [System.IO.FileAccess]::Write,
                    [System.IO.FileShare]::None
                )

            $inputStream.CopyTo(
                $outputStream,
                1048576
            )

            $outputStream.Flush()

            $success = $true

        }
        catch {

            if ($attempt -eq 3) {

                $failed.Add(
                    [PSCustomObject]@{
                        File  = $relative
                        Stage = "copy"
                        Error = $_.Exception.Message
                    }
                )

            }
            else {

                Start-Sleep -Milliseconds 250

            }

        }
        finally {

            if ($outputStream) {
                $outputStream.Dispose()
            }

            if ($inputStream) {
                $inputStream.Dispose()
            }

        }

    }


    if (
        ($i % 100) -eq 0 -or
        $i -eq $total
    ) {

        $pct =
            [Math]::Round(
                ($i / $total) * 100,
                1
            )

        Write-Host "$i / $total ($pct%)"
    }
}


# Report failures
Write-Host ""

if ($failed.Count -gt 0) {

    Write-Host "FAILED: $($failed.Count)"
    Write-Host ""

    $failed |
        Format-Table -AutoSize

}
else {

    Write-Host "All files copied successfully."
}


# Verify important runtime files
$node =
    Join-Path $dst "bin\node.exe"

$nodeRepl =
    Join-Path $dst "bin\node_repl.exe"

$manifest =
    Join-Path $dst "manifest.json"

Write-Host ""
Write-Host "Verification:"
Write-Host ""

Write-Host "node.exe      :" `
    ([System.IO.File]::Exists((Get-LongPath $node)))

Write-Host "node_repl.exe :" `
    ([System.IO.File]::Exists((Get-LongPath $nodeRepl)))

Write-Host "manifest.json :" `
    ([System.IO.File]::Exists((Get-LongPath $manifest)))

Write-Host ""
Write-Host "Runtime:"
Write-Host $dst

After this completed successfully, the runtime existed under the expected content-addressed directory and Codex Desktop was able to show its UI again.

So, at least on my system, there seem to be two interacting Windows problems during cua_node materialization:

WindowsApps Application Protected / encrypted files
        +
very deep pnpm dependency paths
        ↓
incomplete cua_node staging
        ↓
renderer / app initialization does not complete
        ↓
ChatGPT.exe processes exist, but MainWindowHandle = 0
        ↓
no Codex Desktop UI

The per-file stream copy also seems preferable to copying only node_repl.exe, because an incomplete staging directory may be missing many additional files.

For reference, this was reproduced on:

Codex Desktop : 26.901.4073.0
Runtime ID    : c2900163265bdaec
Platform      : Windows x64

Disclosure: I diagnosed the issue interactively and tested the workaround on my machine. The explanation and PowerShell script above were organized and cleaned up with the assistance of OpenAI GPT.

Additional reproduction on Windows:

Codex package: 26.901.1978.0
Runtime hash: ad3b5049246cde44
Multiple .staging-ad3b5049246cde44-* directories were created
The staging runtime contained node.exe but no node_repl.exe or manifest.json
The staging directory continued growing for about 33 minutes
The final ad3b5049246cde44 runtime directory eventually appeared automatically
node_repl.exe and manifest.json were then present and the UI became usable
No manual copy or workaround was performed

This suggests the issue may sometimes self-recover after a very long delay, rather than failing permanently. However, this duration is completely abnormal. The expansion of the node should NOT affect the normal operation of the app!

Confirmed this issue still reproduces on the newer Codex Desktop 26.901.4073.0 MSIX package.

Environment

Windows x64
Microsoft Store / MSIX
Package: OpenAI.Codex_26.901.4073.0_x64__2p2nqsd0c76g0
Package status: Ok

A full uninstall/reinstall of the same version did not change the behavior.

Failure signature

On every failed launch:

Electron main process present
2 crashpad processes
GPU process present
2 utility processes present
no --type=renderer process
no visible window
all MainWindowHandle = 0

The desktop log consistently stopped after only:

Launching app ...
Appshot hotkey inactive configured=true enabled=false platform=win32

The Electron main process continuously consumed CPU while child processes remained mostly idle.

Runtime staging evidence

This build expects the following cua_node runtime:

c2900163265bdaec

The machine previously only had the older finalized runtime:

415ffebf3d576e9b

Each failed launch created another directory similar to:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-c2900163265bdaec-*

The staging process never finalized. The incomplete staging directory consistently stopped at only a handful of files: node.exe was present while node_repl.exe and additional runtime files were missing. The corresponding files inside the installed MSIX package are present and marked Application Protected.

EFS itself is working

One difference from some related reports: EFS does not appear to be broken on this machine.

I performed a real EFS round-trip test on a temporary NTFS file:

cipher /e
verified the encrypted file remained readable
cipher /d

Encryption and decryption both completed successfully.

So this failure can occur on a Windows system where normal user EFS functionality is healthy.

Workaround

With all Codex / ChatGPT.exe processes stopped, I manually pre-populated the runtime expected by this build.

The package's complete:

app\resources\cua_node

was copied using xcopy /G into:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\c2900163265bdaec

The resulting runtime contained approximately:

4683 files
~322 MB

including both:

bin\node.exe
bin\node_repl.exe

No files under C:\Program Files\WindowsApps were modified.

Result

Immediately after pre-populating the expected runtime, Codex started successfully.

Before workaround:

MainWindowHandle = 0
renderer count   = 0
startup log      = 2 lines

After workaround:

MainWindowHandle != 0
renderer count    = 3

The startup log expanded to ~251 lines and included:

window ready-to-show
Codex CLI initialized
renderer routes mounted

The application became fully usable.

Interestingly, after successful startup Codex automatically cleaned up the failed .staging-* directories and the previous 415ffebf3d576e9b runtime, leaving only the expected:

c2900163265bdaec

Conclusion

This is a strong A/B reproduction pointing to the Windows/MSIX cua_node runtime materialization/relocation path:

new cua_node runtime required
→ Application Protected package resources need relocation
→ Codex staging remains incomplete
→ startup blocks before app-server / BrowserWindow / renderer creation
→ headless Electron main process with sustained CPU usage

pre-populate the exact runtime using xcopy /G
→ runtime is complete
→ BrowserWindow and renderer processes are created
→ Codex starts normally

This also suggests the issue is not limited to systems with broken EFS, since EFS encryption/decryption works correctly here.

The important regression is that a runtime relocation failure can block the entire desktop startup path without surfacing the actual relocation error to the user.

Ideally the Windows materialization path should either:

support copying Application Protected resources to a decrypted destination (semantics equivalent to what makes xcopy /G succeed), or
fall back to a normal buffered/stream copy,

and an incomplete runtime staging operation should fail visibly rather than leaving the Electron main process running headlessly.

This issue therefore still appears to be present in 26.901.4073.0.

Confirming that this issue still exists in 26.901.5280.0 on Windows (Microsoft Store/MSIX).

After updating, ChatGPT.exe processes start and remain running, but no UI appears (MainWindowHandle = 0, with no renderer process).

Under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node, multiple .staging-440c4f095d41ea30-* directories were created. They contained node.exe, but node_repl.exe and manifest.json were missing.

I fixed it by stopping ChatGPT and copying the complete app\resources\cua_node runtime from the installed MSIX package into the expected 440c4f095d41ea30 runtime directory using xcopy /E /I /H /Y /G.

After that, the UI opened immediately, and normal launches from the Windows Start menu also worked again.

Still broken on 26.901.5003.0. Same machine, three consecutive versions, three fresh runtime hashes, two hard failures.

Windows 11 Home China (CoreCountrySpecific, build 10.0.26200), Store/MSIX, x64.

Hash sequence on a single machine

Package version	Expected runtime dir	Outcome
`26.901.1978.0`	`ad3b5049246cde44`	staging stalled, no UI — manual copy required
`26.901.4073.0`	`c2900163265bdaec`	self-recovered after a long delay
`26.901.5003.0`	`6a86821985684e13`	staging stalled again, no UI

Because the destination directory name is version-derived, every single update re-runs the same doomed copy. There is no stable state a user can reach. Fixing it by hand does not protect you from the next Store update — and Store updates are automatic by default, so the app breaks itself at a time the user did not choose and cannot predict.

The `4073` → `5003` contrast has not been reported yet

Same machine, same OS, same filesystem, same account, same package family — one version materialized its runtime on its own, the very next one did not. That makes this a race/timeout, not a deterministic failure, and it independently corroborates the ~33-minute self-recovery reported earlier in this thread. Whatever retry budget the materializer has, it is sitting right at the edge of the wall-clock cost of 4,683 doomed copies (see #41822). That is why reports in this thread look inconsistent: some users get a slow success, some get an infinite hang, and it is the same bug.

Measured on the failing version

Source app\resources\cua_node: 4,683 files / 337,645,144 bytes
Files carrying the NTFS Encrypted attribute: 4,683 / 4,683
fsutil behavior query disableencryption → DisableEncryption = 0 — this is an edition limitation, not a policy toggle. Home SKUs have no EFS and can never create these files.
Failing staging dirs contain bin\node.exe but never bin\node_repl.exe or manifest.json
The package dir is owned by NT AUTHORITY\SYSTEM and Store-signed, so users cannot patch the copy logic themselves even if they diagnose it

Cost of the attribute propagation

Method	Time	Result
App's own materializer	33 min best observed case, indefinite otherwise	usually no UI, ever
`robocopy /E /COPY:DT /DCOPY:T`	~7 min	`FAILED: 0`, 0 files with `Encrypted` at destination

The only difference is /COPY:DT — copy Data and Timestamps, drop Attributes. One flag. That is the entire bug.

Why this deserves more urgency than it is getting

This is not a degraded feature or an edge case. The application does not open at all. And it fails in the worst possible way:

No error dialog. No crash. No log entry. The desktop log stops after Launching app ... and nothing else is ever written.
ChatGPT.exe processes start and sit there consuming CPU with MainWindowHandle = 0, so the OS thinks the app is running fine. The user double-clicks the icon and nothing happens, repeatedly, with zero feedback.
Nothing in the UI, the installer, or the docs points at %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node. A normal user has no path to the diagnosis. Multiple people in this thread confirmed that a full uninstall/reinstall does not help — which is exactly what a normal user will try, and it costs them a 300+ MB re-download to end up in the same place.
Computer Use is disabled in my config. I am paying the entire cost of materializing a 322 MB runtime for a feature I do not use, and it takes the whole application down with it. A runtime for an optional subsystem should never be a hard blocker on the main window appearing.

The blast radius is not small: Home is the default SKU on essentially every consumer Windows machine. Pro and Enterprise have EFS so the attribute propagates fine and nobody internally sees this — which is presumably why it shipped. That is not a reason for it to survive six days. It means the entire consumer Windows install base is the affected population and none of you are in it.

Status of this bug in the repo

Reproducible for six days straight across 1978 / 2854 / 4073 / 5280 / 5003 — five releases. You have shipped repeatedly during that window and not one of those releases touched this code path.

Searching this repository for cua_node returns 169 issues and zero pull requests. This issue has eight comments, all from affected users doing your triage for you, and no response from anyone at OpenAI. No assignee. No milestone. #41822 has had the mechanism spelled out in its literal title since August 31st.

The fix is one flag in one copy call, and it has been sitting in this thread, fully diagnosed with reproduction steps and measurements, for days.

Please assign this and ship it. At absolute minimum, acknowledge it publicly so the people hitting a silently dead application know it is on the board.

Independent confirmation on another affected machine.

### Environment:

Codex Desktop 26.901.1978.0
Windows 11 25H2, build 26200.9168
x64 / Intel Core i5-13420H
Microsoft Store / MSIX

I observed the same background-only startup behavior with MainWindowHandle = 0.

I also reproduced the issue from a completely fresh local Windows user profile, which rules out my existing per-user Codex configuration/state.

Manually staging cua_node to runtime ad3b5049246cde44 using xcopy /E /I /H /Y /G completed with 4683 files. Both bin\node.exe and bin\node_repl.exe were present afterward, and Codex launched normally immediately.

I also reported this reproduction to OpenAI Support under Case #14288515; support has added the cua_node staging findings and workaround to the case.

So this is another independent confirmation of the same runtime-materialization failure rather than a user-profile or rendering configuration issue.

Update: reproduced again on `26.901.6511.0`

I can confirm that this issue is still reproducible on a newer Microsoft Store build, 26.901.6511.0, on the same Windows machine.

I previously encountered the same problem on 26.901.5280.0. At that time, manually restoring the required cua_node runtime with xcopy /G fixed the application, and Codex/ChatGPT Desktop launched normally afterwards.

After updating to 26.901.6511.0, the problem returned:

ChatGPT.exe started and remained responsive, but no UI appeared.
MainWindowHandle remained 0.
GPU/network/storage utility processes were present, but no --type=renderer process was created.
The new expected runtime ID was b474a88d5d105afa.
Every launch created another incomplete .staging-b474a88d5d105afa-* directory.
In all of these staging directories:
- bin\node.exe was present;
- bin\node_repl.exe was missing;
- manifest.json was missing.
The bundled runtime under app\resources\cua_node was complete, including node_repl.exe.

The previously repaired runtime from 26.901.5280.0 (440c4f095d41ea30) was still complete, but it did not help because the new build required the new runtime ID.

I again copied the complete bundled runtime to:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\b474a88d5d105afa

using xcopy /G. It copied 4683 files successfully (exit code 0), and SHA-256 checks for manifest.json, node.exe, and node_repl.exe all matched the packaged source.

After this, the application immediately launched normally again.

So this appears to confirm that the issue can recur across application updates whenever the required cua_node runtime hash changes, and that the underlying staging/relocation problem is still present in 26.901.6511.0.

Independent reproduction on `26.901.6511.0` with repeated near-complete staging

I can independently reproduce the same failure on Microsoft Store/MSIX build OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0.

Startup diagnostics on the affected machine:

multiple packaged ChatGPT.exe processes start, but Codex has no usable UI;
a standalone CLI is configured via CODEX_CLI_PATH at %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe and the file exists, so this is not a missing-CLI-path problem;
the previous finalized cua_node runtime (440c4f095d41ea30) is still present;
the new build expects runtime hash b474a88d5d105afa and repeatedly fails to finalize it.

Within about 15 minutes, five new staging directories were created:

.staging-b474a88d5d105afa-bT1yoT
.staging-b474a88d5d105afa-vwIbtZ
.staging-b474a88d5d105afa-zHct0B
.staging-b474a88d5d105afa-LWZb4x
.staging-b474a88d5d105afa-lBvmzW

Every one had the same partial state:

bin\node.exe                  = present
bin\node_repl.exe             = missing
bin\node_modules\@oai         = present
bin\node_modules\.pnpm        = present

So each launch is doing substantial runtime materialization, reaches essentially the same protected-file boundary, abandons that staging tree, then creates a fresh staging directory on the next attempt.

One practical observation: a full-tree xcopy /G repair is relatively slow because it re-walks/re-copies thousands of files even though the staging tree is already largely populated. I am testing an adaptive repair approach that reuses the most complete staging tree, compares it against the packaged app\resources\cua_node, copies only missing/newer files using xcopy /G, verifies manifest.json / node.exe / node_repl.exe, and then finalizes the staging directory.

This suggests the product-side recovery path could also be improved by resuming an existing near-complete staging tree (or retrying only the failed protected-file copy) instead of starting another full staging tree after each failure. A bounded retry plus COPY_FILE_ALLOW_DECRYPTED_DESTINATION-equivalent behavior for protected files would avoid both the headless startup and repeated disk/work amplification.

Confirmed again on Codex `26.903.8094.0`

I reproduced the same Microsoft Store/MSIX cua_node staging failure after updating to:

OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0

The new expected runtime was:

b58ca2eaa616c2da

Three launch attempts left incomplete staging directories:

  .staging-b58ca2eaa616c2da-DCsEs8
  .staging-b58ca2eaa616c2da-gZKzaZ
  .staging-b58ca2eaa616c2da-QyYXuj

They contained only 450, 309, and 324 files. The complete packaged runtime contained:

  Files:        4052
  Bytes:        261658343
  Bundled Node: v24.20.0

The previously repaired runtime for 26.901.6511.0 still existed, but it did not help because this update required a
new content hash.

Copying the bundled runtime into:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da

with data-only semantics fixed the app:

robocopy.exe $source $destination /E /COPY:DT /DCOPY:T /R:1 /W:1

Verification showed identical source/destination file and byte totals. The copied bin\node.exe reported v24.20.0.
Codex then activated successfully, its processes remained responsive, and no new staging directories appeared.

This confirms the defect still recurs whenever an update changes the expected cua_node runtime hash. It is not fixed
by updating the globally installed Node.js.

I can reproduce the same cua_node runtime staging failure on Codex for Windows 26.903.8094.0, and I was able to isolate the exact file that caused staging to remain incomplete.

Environment

Codex package: OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0
Platform: Windows x64
Install type: Microsoft Store / MSIX
Runtime root: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node
Expected runtime ID: b58ca2eaa616c2da

Failure symptoms

Before the workaround:

multiple ChatGPT.exe processes started
GPU/network/storage utility processes were present
all Codex ChatGPT.exe processes had MainWindowHandle = 0
no visible Codex window was created
no ChatGPT.exe --type=renderer processes were created
no codex.exe ... app-server process was created

Every launch generated another incomplete directory:

.staging-b58ca2eaa616c2da-*

The newest failed staging directory had only 2,280 files and contained:

bin\node.exe — present
bin\node_repl.exe — missing
manifest.json — missing

The bundled runtime in the MSIX package contained 4,052 files, including all three.

Exact file-copy failure

I manually copied the bundled cua_node runtime.

xcopy /E /I /H /Y /G reported success but copied only 4,051 of 4,052 files.

The single missing file was:

bin\node_modules\@oai\sky\dist\js-dependency-cache\shared-v1\applied-bk-agent-openai-js\pnpm-store\v11\links\@rollup\plugin-typescript\12.1.2\bf978194e78e4126a616bfdc5a9fea913609f48ddc1a68ce028d4322c58982dd\node_modules\tslib\tslib.es6.js

Source properties:

size: 1,426 bytes
attributes: Archive, Encrypted

Trying to copy this file directly with xcopy failed.

I then temporarily shortened the source and destination paths using subst. The effective paths became 241 characters. Using:

copy /D /Y

successfully copied the file in decrypted form.

Verification after the copy:

source and destination SHA-256 hashes matched
destination attributes became Archive
source runtime files: 4,052
destination runtime files: 4,052
missing files: 0

Result

After the runtime was complete, Codex launched normally.

I then observed:

Codex main window successfully created
MainWindowHandle became non-zero (396198)
multiple ChatGPT.exe --type=renderer processes appeared
codex.exe ... app-server started successfully
the app-server command explicitly referenced:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da\bin\node.exe

This looks like the same Windows runtime materialization/EFS problem, but in 26.903.8094.0 I was able to narrow it down to a specific encrypted file located under a very long pnpm dependency-cache path.

It may be worth checking whether the runtime staging implementation needs both long-path-safe handling and the equivalent of COPY_FILE_ALLOW_DECRYPTED_DESTINATION when materializing protected/EFS files from the MSIX package.

Reproduced again on a newer Windows Store build, with an additional long-path/EFS detail that may help narrow down the relocation failure.

Environment

Codex MSIX: OpenAI.Codex 26.903.8094.0 (x64)
Windows 11 25H2, build 26200.9445
Runtime root: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

Observed state

The runtime root contained 20 failed staging directories, all for the same runtime ID:

.staging-b58ca2eaa616c2da-*

The expected final directory did not exist:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da
DestinationExists: False
DestinationFiles: 0

The packaged source runtime existed and contained 4052 files.

Before repairing the runtime, each launch created the Electron main Chrome_WidgetWin_* window, but it became hung after roughly six seconds. Normal launch and --disable-gpu behaved the same way. A clean Chromium profile and a clean temporary CODEX_HOME did not change the failure.

Copy result and the one file `xcopy /G` missed

Running the workaround with xcopy /E /I /H /Y /G reported:

4051 File(s) copied

One encrypted file was still missing:

bin\node_modules\@oai\sky\dist\js-dependency-cache\shared-v1\
applied-bk-agent-openai-js\pnpm-store\v11\links\@rollup\
plugin-typescript\12.1.2\
bf978194e78e4126a616bfdc5a9fea913609f48ddc1a68ce028d4322c58982dd\
node_modules\tslib\tslib.es6.js

Details:

Source attributes: Archive, Encrypted
Source full path length: 336
Destination full path length: 316
File size: 1426 bytes

robocopy also failed for that file with:

ERROR 6000 (0x00001770)
The specified file could not be encrypted.

I copied the final file using long-path-aware Win32/.NET paths while writing a decrypted destination. The final runtime verified as:

Source files:      4052
Destination files: 4052

Recovery validation

I then launched with CODEX_SPARKLE_ENABLED=false through Invoke-CommandInDesktopPackage.

After the complete runtime was present:

the real Chromium main window stayed IsHungAppWindow=False for all 10 samples over 30 seconds;
a later 10-consecutive-check startup validation also passed;
a subsequent delayed health check passed without restarting the process;
the UI became usable again.

This installation therefore appears to hit the same incomplete cua_node materialization issue on 26.903.8094.0. The additional failure mode here is that even xcopy /G can silently leave the runtime incomplete when an EFS-protected source file also has a path longer than the legacy Win32 limit.

Privacy note: usernames, account identifiers, project paths, session data, and raw logs have been omitted.

Confirming this bug with a longer timeline: it has reproduced on 7 consecutive Store updates, including the latest build.

Environment: Windows 11 (10.0.26200), MSIX package OpenAI.Codex_..._2p2nqsd0c76g0.

Affected versions — every single update since late August:

#	Version	Runtime ID
1	26.901.1978.0	`ad3b5049246cde44`
2	26.901.4073.0	`c2900163265bdaec`
3	26.901.5280.0	`440c4f095d41ea30`
4	26.901.6511.0	`b474a88d5d105afa`
5	26.903.8094.0	`b58ca2eaa616c2da`
6	26.903.9818.0	`e7fe122ad3cbcd58`
7	26.908.4834.0 (latest as of 2026-09-12)	`a708e72b10c27b59`

Symptoms identical each time: several ChatGPT.exe processes (MAIN/GPU/UTILITY/CRASHPAD), no --type=renderer process ever spawns, MainWindowHandle = 0, main process spinning ~2 cores, MoAppHang in the Event Log, no crash dumps. New .staging-<runtime-id>-* dirs accumulate (34 of them after the first occurrence), each containing everything except bin\node_repl.exe. cipher /c on the packaged source confirms node_repl.exe carries the Application Protected (EFS) attribute, while every other file in the package stages fine.

Workaround, verified 7/7: stop all ChatGPT.exe, xcopy /E /I /H /Y /G the package's app\resources\cua_node into a temp dir (the /G decrypted copy reads the protected file), verify SHA256 of manifest.json / bin\node.exe / bin\node_repl.exe, atomically rename to <runtime-id>, move staging debris aside, relaunch via AUMID (shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App). Window appears ~30 s after relaunch, every time.

Two extra data points that may help whoever picks this up:

On builds 26.901.5280.0 → 26.903.9818.0, xcopy also silently skipped one >260-char path (bin\node_modules\@oai\sky\...\tslib\tslib.es6.js); on 26.908.4834.0 all 4123 files copy cleanly. So the long-path gap is orthogonal — the protected-file gap is the constant.
The staging loop never times out or surfaces any error to the user; the app just burns CPU forever. Even a retry cap plus a "runtime staging failed" dialog would turn this from "app is dead" into "app tells me what happened".

Happy to provide staging dirs, hashes, or event logs if useful.

This issue is still reproducible on OpenAI.Codex 26.908.4834.0.

After the update, ChatGPT.exe processes started normally, but there was no visible window, no --type=renderer process, and all MainWindowHandle values remained 0.

The new runtime ID was:

a708e72b10c27b59

Multiple failed staging directories were created:

.staging-a708e72b10c27b59-*

and they consistently contained:

node.exe        present
node_repl.exe   missing
manifest.json   missing

The packaged runtime under app\resources\cua_node was complete.

I again worked around the problem by stopping ChatGPT and copying the complete bundled cua_node runtime into:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a708e72b10c27b59

using xcopy /E /I /H /Y /G.

This copied 4123 files with exit code 0. After relaunching, multiple ChatGPT.exe --type=renderer processes appeared and the main window was restored (MainWindowHandle changed from 0 to a non-zero value).

This is now a recurring regression across multiple Codex/ChatGPT Windows updates on the same machine. The manual runtime repair works, but every new runtime ID can trigger the same failure again.

As a temporary mitigation, I have had to disable both update paths:

CODEX_SPARKLE_ENABLED=false
Microsoft Store AutoDownload=2

to prevent another update from making the desktop app unusable again.

This is quite disruptive because a normal automatic update can leave ChatGPT apparently running in the background while the UI is completely inaccessible.

Please prioritize a proper fix for the cua_node staging/relocation path on Windows, including recovery from incomplete .staging-* runtimes. Users should not have to manually reconstruct the runtime or freeze application updates just to keep the desktop client usable.

I am seeing a closely related issue on Windows 10 with Codex Desktop 26.903.9818.0 (and previously 26.903.8094.0).

Symptoms

After the update, Codex starts very slowly and repeatedly becomes unresponsive when moving the mouse over the window, clicking, or typing. If I leave it running instead of force-closing it, the UI may recover temporarily and then freeze again.

Diagnostics

One affected startup took about 52 seconds.
Runtime deployment repeatedly logged bundled_executable_relocation_failed.
Failing operation: rename_staging
Error: EPERM
Target runtime directory:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\e7fe122ad3cbcd58
Logs around the same period also showed repeated UI/main-thread stalls.
Inspection of the installed app code suggests the runtime copy/rename path uses synchronous filesystem operations. Repeated deployment retries after relocation failure may therefore block a UI-critical execution path for extended periods.

The underlying reason Windows returns EPERM for the directory rename is still unknown.

Workaround / confirmation

As a workaround, I manually copied the complete runtime from the installed package's resources\cua_node directory into the expected runtime destination, bypassing the failing staging-directory rename step.

I verified:

presence and file sizes for 4,052 files
SHA-256 hashes of the two core executables against the originals

After populating the runtime manually:

plugin/runtime initialization completed successfully
repeated deployment failures stopped
the Codex UI became responsive again

This strongly suggests that the runtime deployment/relocation failure is related to the UI hangs.

Suggested improvement

Move runtime deployment off any UI-critical/main-thread path
Avoid synchronous filesystem operations on that path
Add retry backoff instead of immediate repeated deployment attempts
Surface a clear error when runtime relocation repeatedly fails

This would prevent a runtime deployment failure from making the entire desktop UI appear frozen.

Update: 8th consecutive Store update, 8th failure — this is now shipping at a pace where every user with auto-update enabled is guaranteed a broken app.

New occurrence (2026-09-15):

#	Version	Runtime ID
8	26.908.9136.0 (current latest)	`6f12e0ef1c6e5061`

Same signature: multiple ChatGPT.exe processes, no --type=renderer, MainWindowHandle = 0, main process burning ~2 cores, fresh .staging-6f12e0ef1c6e5061-* dirs missing only bin\node_repl.exe. Same workaround fixes it (xcopy /G + atomic install + AUMID relaunch, renderer up in ~30 s).

One additional data point since my last comment: builds 26.908.4834.0 and 26.908.9136.0 (4123 files each) now stage all files via plain xcopy /G — the >260-char tslib.es6.js skip from builds 26.901.5280.0 → 26.903.9818.0 is gone. So path length was never the constant; the Application Protected attribute on the packaged node_repl.exe is the one and only consistent blocker across all 8 builds. Whatever fix lands needs to address that attribute (or stage the runtime from a non-encrypted source), not path handling.

Also worth noting the release cadence: 26.903.9818.0 (Sep 11) → 26.908.4834.0 (Sep 12) → 26.908.9136.0 (Sep 15). Three broken updates in five days. Until this is fixed, each release re-bricks the app for affected machines — a staging retry cap plus a visible "runtime staging failed" error would at least make the failure diagnosable for normal users.

One factor worth checking is whether Codex is installed on the system drive or a secondary drive.

I compared two Windows machines: Codex’s package files were encrypted on the machine where it was installed on D: (the non-system drive), but unencrypted on the machine where it was installed on C: (the system drive).

I had encountered EFS-related failures when Codex copied its bundled resources. Moving the affected installation from D: to C: resolved the problem for me, and Codex started normally afterward.

Microsoft documents that MSIX encrypts package files on non-system package volumes, while the system package volume is exempt: [MSIX PackageVolume: How Package Storage Works](https://devblogs.microsoft.com/insidemsix/msix-packagevolume/).

This may help explain why some installations encounter protected-file copying problems while others do not.

Update: the issue recurred again on `26.911.7940.0`, after I had already tried to disable automatic updates

I have now reproduced this same cua_node staging failure across multiple Codex/ChatGPT Windows versions. This time there is an additional finding that may be relevant: I had already tried to stop automatic updates after the previous recurrence, but Windows still updated the package, and the next update triggered the same no-UI failure again.

Update controls already configured

After the previous failure, I configured both of the following:

CODEX_SPARKLE_ENABLED=false

and:

HKLM\SOFTWARE\Policies\Microsoft\WindowsStore
AutoDownload = 2

The first setting was definitely effective for the Codex in-app updater. Subsequent Codex logs consistently showed:

enableSparkle=false
enableUpdater=false

So the later update was not initiated by the Codex in-app updater.

For the Store setting, AutoDownload=2 was still present when I checked it. However, this machine is using a Windows Home China SKU (build 26200), and the setting did not appear as an effective policy under PolicyManager\current or in gpresult. Therefore, I cannot confirm that this Store policy was actually enforced on this Windows edition.

Windows still updated Codex through the Windows Update / Store path

The Windows Store / Install Service event logs show that the later updates were initiated by Windows Update Orchestrator / MoUsoCoreWorker, for example:

FulfillmentPluginId = WU

ClientAppId =
Update;MoUpdateOrchestratorUserScan-
MoUsoCoreWorker-
SearchForAllUpdatesWithUpdateOptionsAsync

On September 17, Windows downloaded and installed:

OpenAI.Codex_26.911.7940.0_x64__2p2nqsd0c76g0

The download size recorded by the Store Install Service was:

634231285 bytes

and AppXDeploymentServer subsequently recorded:

OpenAI.Codex_26.908.4834.0
is updating to
OpenAI.Codex_26.911.7940.0

The package update itself completed successfully.

Immediately afterward, the same `cua_node` failure occurred again

After 26.911.7940.0 was installed, launching ChatGPT produced background processes but no UI:

Renderer count: 0
MainWindowHandle: 0

The new expected runtime was:

fcf5d08964516500

Two consecutive staging attempts were created:

.staging-fcf5d08964516500-cP9p1r
.staging-fcf5d08964516500-vH7e0k

Both failed in exactly the same state:

node.exe       = present
node_repl.exe  = missing
manifest.json  = missing

At the same time, the files bundled inside the installed MSIX were complete:

app\resources\cua_node\manifest.json       = present
app\resources\cua_node\bin\node.exe        = present
app\resources\cua_node\bin\node_repl.exe   = present

So this was again a failure while materializing/relocating the bundled cua_node runtime, not a missing file in the package itself.

The same manual workaround fixed it again

With all ChatGPT.exe processes stopped, I manually copied the packaged cua_node directory into:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\fcf5d08964516500

using xcopy /G.

Result:

4123 files copied
xcopy exit code: 0

I then verified SHA-256 equality between the package source and the rebuilt runtime for:

manifest.json      -> Match = True
bin\node.exe       -> Match = True
bin\node_repl.exe  -> Match = True

After that, ChatGPT launched normally and the UI immediately returned.

Current failure chain

The sequence on this machine is now effectively:

Codex in-app updater disabled
        ↓
Windows Update / MoUsoCoreWorker still discovers a newer Store package
        ↓
OpenAI.Codex is updated
        ↓
new cua_node runtime hash is required
        ↓
automatic runtime staging is incomplete
        ↓
node.exe copied
node_repl.exe / manifest.json missing
        ↓
renderer never starts
MainWindowHandle remains 0
        ↓
ChatGPT has background processes but no UI
        ↓
manual xcopy /G of the bundled runtime
        ↓
UI works again

This is particularly disruptive because the workaround only repairs the current runtime hash. A later package update introduces another runtime hash and the same failure can occur again.

It would be very helpful if the Windows runtime materialization path could be fixed so that protected/MSIX-packaged files can be copied reliably without requiring manual xcopy /G.

It would also be useful for the app to detect an incomplete .staging-* runtime and report the actual relocation/copy failure instead of remaining indefinitely as responsive background processes with no window.

Finally, since disabling the Codex in-app updater does not prevent Windows Update / Store servicing from replacing the MSIX package, a supported way to temporarily defer desktop-app updates would also be valuable for users affected by a version-dependent startup regression like this.

@TarryFu

Update: 9th failure on my machine with the current latest build, plus one new data point that may explain why this bug is hard to reproduce consistently internally.

New occurrence (2026-09-25): 26.917.8451.0, runtime id 7f75cff94511d5f8 (node bumped to v24.21.0). Same signature as all previous occurrences (no renderer, MainWindowHandle = 0, staging dirs missing only bin\node_repl.exe), same xcopy /G workaround fixes it. Two changes in this build: the bundled runtime shrank from 4123 to 2283 files, and the whole manual repair now takes ~7 minutes.

The interesting part: between my 8th failure (26.908.9136.0, Sep 15) and this one, an intermediate build staged its runtime (f53823cd54b14f45) successfully on its own around Sep 23 — the first build since late August that didn't brick the app. But @TarryFu reports 26.911.7940.0 failing on their machine (Sep 20). That leaves two possibilities:

My Sep 23 build was newer than 26.911.7940.0 and genuinely shipped without the Application Protected attribute on node_repl.exe — i.e. the attribute comes and goes per packaging run, which would match the "some builds break, some don't" pattern across this thread; or
The same version can both fail and succeed depending on the machine — which would point at the delivery path or local EFS state, not just package content.

Either way, it reinforces that the trigger is the (intermittently present) Application Protected / EFS attribute on the packaged node_repl.exe, and that a fix in the staging logic (decrypted-copy fallback, or shipping the runtime unencrypted) would make this whole class of failures disappear. The ask from my previous comment stands: even without a full fix, a staging retry cap plus a visible "runtime staging failed" error would stop users from seeing a silently bricked app.

[Windows] 26.901.1978.0 fails to launch UI when cua_node staging cannot copy node_repl.exe #42501

Description

Summary

Environment

Symptoms

Runtime staging evidence

Workaround that fixed the launch

Expected behavior

Why this is particularly disruptive

Related

Activity

github-actions commented on Sep 3, 2026

upeirgranuccihs-collab commented on Sep 4, 2026

Weiyuantong commented on Sep 4, 2026

yuyu-111000 commented on Sep 4, 2026

YetongW commented on Sep 4, 2026

What I found

Workaround that worked for me

xiaokai-lyk commented on Sep 4, 2026

sdfsjagfdgas commented on Sep 4, 2026

Environment

Failure signature

Runtime staging evidence

EFS itself is working

Workaround

Result

Conclusion

TarryFu commented on Sep 5, 2026

sleepyy-dog commented on Sep 6, 2026

Hash sequence on a single machine

The 4073 → 5003 contrast has not been reported yet

Measured on the failing version

Cost of the attribute propagation

Why this deserves more urgency than it is getting

Status of this bug in the repo

ThuocLQ commented on Sep 7, 2026

TarryFu commented on Sep 8, 2026

Update: reproduced again on 26.901.6511.0

BeyondLiby commented on Sep 9, 2026

Independent reproduction on 26.901.6511.0 with repeated near-complete staging

Vijayabhaskar96 commented on Sep 9, 2026

Confirmed again on Codex 26.903.8094.0

YueDong0211 commented on Sep 10, 2026

Environment

Failure symptoms

Exact file-copy failure

Result

Arison591 commented on Sep 10, 2026

Environment

Observed state

Copy result and the one file xcopy /G missed

Recovery validation

lavine888 commented on Sep 12, 2026

TarryFu commented on Sep 12, 2026

Sugarcgmade commented on Sep 13, 2026

Symptoms

Diagnostics

Workaround / confirmation

Suggested improvement

lavine888 commented on Sep 15, 2026

shkero commented on Sep 18, 2026

TarryFu commented on Sep 20, 2026

Update: the issue recurred again on 26.911.7940.0, after I had already tried to disable automatic updates

Update controls already configured

Windows still updated Codex through the Windows Update / Store path

Immediately afterward, the same cua_node failure occurred again

The same manual workaround fixed it again

Current failure chain

lavine888 commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

The `4073` → `5003` contrast has not been reported yet

Update: reproduced again on `26.901.6511.0`

Independent reproduction on `26.901.6511.0` with repeated near-complete staging

Confirmed again on Codex `26.903.8094.0`

Copy result and the one file `xcopy /G` missed

Update: the issue recurred again on `26.911.7940.0`, after I had already tried to disable automatic updates

Immediately afterward, the same `cua_node` failure occurred again