Computer Use unavailable on Windows: Application Protected files fail to copy from WindowsApps #34764

Activity

1. lizixian518-cell

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 22, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   computer-use

   on Jul 22, 2026
3. github-actions commented on Jul 22, 2026

   

   github-actionsBot

   on Jul 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows] ChatGPT.exe uses 15–25% CPU while idle due to repeated executable relocation and plugin sync failures #34541

   Powered by Codex Action
4. wantknowmore commented on Aug 10, 2026

   

   wantknowmore

   on Aug 10, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced on another Windows 11 Microsoft Store installation and this also causes noticeably slow app startup.

   Environment:

   • Store package: OpenAI.Codex 26.715.9079.0
   • Windows 11 x64
   • Install method: Microsoft Store / MSIX

   Observed startup timing from the desktop log:

   • app launch -> ready-to-show: ~9.6 s
   • app launch -> renderer routes mounted: ~15.4 s
   • Store update check: ~2.0 s
   • bundled executable relocation retries: ~4.0 s before the app server can spawn
   • an additional Git-origins scan completed in ~6.9 s after the window was shown

   The relocation failures repeatedly include rg.exe, codex.exe, and the cua_node runtime:

   bundled_executable_relocation_failed
   errorCode=UNKNOWN
   originalError={ errno: -4094, code: UNKNOWN, syscall: copyfile }
   sourceKind=windowsapps
   

   Independent reproduction (redacted paths): the package source exists, but copying ...\\WindowsApps\\OpenAI.Codex_...\\app\\resources\\rg.exe to an ordinary user-writable directory fails with:

   The specified file could not be encrypted.
   HRESULT: -2147018896
   

   The destination cache directories are writable, so this does not appear to be ordinary user-cache permissions. No active reconnect/network failure was present in this startup. This extends the impact beyond Computer Use: the repeated relocation attempts materially delay first usable UI.
5. Yajuju207 commented on Aug 11, 2026

   

   Yajuju207

   on Aug 11, 2026 – with ChatGPT Codex Connector

   More actions

   I reproduced this issue and found a working workaround on my machine that may help narrow the root cause.

   Environment

   • Windows 11 x64 / 10.0.26200.8875
   • Edition: CoreCountrySpecific
   • Codex package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
   • Microsoft Store: 22606.1401.13.0
   • App Installer: 1.29.280.0

   Before the workaround:

   Computer Use plugin exists = True
   CUA source exists          = True
   CUA SOURCE FILES           = 3452
   
   cipher /c node_repl.exe:
   E node_repl.exe
     Compatibility Level:
       Application Protected
   
   CUA DEST EXISTS            = True
   CUA DEST FILES             = 0
   node_repl.exe exists          = False
   codex-computer-use.exe exists = False
   helper_transport.js exists    = False
   

   The bundled marketplace copy did contain computer-use, but the CUA runtime relocation did not complete and no Computer Use backend process was present.

   Important AppxVolume finding

   The surprising part was that Get-AppxPackage OpenAI.Codex reported an InstallLocation shaped like:

   C:\Program Files\WindowsApps\OpenAI.Codex_...
   

   but the package was actually registered on my non-system D: AppxVolume.

   $cVol = Get-AppxVolume -Path C:\
   $dVol = Get-AppxVolume -Path D:\
   
   Get-AppxPackage -Volume $cVol | Where-Object Name -eq 'OpenAI.Codex'
   # no result
   
   Get-AppxPackage -Volume $dVol | Where-Object Name -eq 'OpenAI.Codex'
   # OpenAI.Codex returned here

   The AppX deployment log also explicitly showed target volume D:.

   My volumes were:

   C:\Program Files\WindowsApps   IsSystemVolume=True
   D:\WindowsApps                 IsSystemVolume=False
   

   A control machine with the same Windows build, same Store/App Installer versions, and a working Computer Use installation had Codex on the system AppxVolume and its packaged node_repl.exe was reported as U (unencrypted).

   Workaround that restored Computer Use

   I fully exited Codex and moved the already-installed package to the system AppxVolume using the built-in Appx cmdlet:

   $pkg  = Get-AppxPackage OpenAI.Codex
   $cVol = Get-AppxVolume -Path C:\
   Move-AppxPackage -Package $pkg.PackageFullName -Volume $cVol

   Then I verified:

   Get-AppxPackage -Volume (Get-AppxVolume -Path C:\) |
     Where-Object Name -eq 'OpenAI.Codex'
   # package present
   
   Get-AppxPackage -Volume (Get-AppxVolume -Path D:\) |
     Where-Object Name -eq 'OpenAI.Codex'
   # no result

   After reopening Codex, Computer Use immediately appeared in the Plugins UI and could be installed. I then confirmed that it actually worked by using Computer Use to open Notepad and type text.

   So on this machine, moving Codex from a non-system AppxVolume to the system AppxVolume was sufficient to restore Computer Use, even though the ordinary InstallLocation string had previously looked like a C:\WindowsApps path.

   This may be useful as both a workaround and a diagnostic clue: InstallLocation alone did not reveal the actual AppxVolume association. Get-AppxPackage -Volume ... and the AppX deployment log did.

   I did not modify WindowsApps ACLs, ownership, EFS state, package files, registry values, or app.asar.

   👍React with 👍2Reacted by wanger207 and Zhuochun
6. Yajuju207 commented on Aug 11, 2026

   

   Yajuju207

   on Aug 11, 2026 – with ChatGPT Codex Connector

   More actions

   I published the AppxVolume diagnostic/workaround from my reproduced case as a small public repository:

   https://github.com/Yajuju207/codex-windows-appxvolume-fix

   It includes:

   • diagnose.ps1: read-only checks for the actual AppxVolume association, packaged cua_node state, runtime file count, helper files, and recent AppX deployment evidence.
   • fix-appxvolume.ps1: guarded Move-AppxPackage workaround; dry-run by default and only performs the move with -Apply.
   • docs/case-study.md: sanitized before/after evidence from the failing non-system AppxVolume state and the working system AppxVolume state.

   The repository deliberately does not modify WindowsApps ACLs/ownership, decrypt package files, patch app.asar, or redistribute OpenAI binaries.

   For my machine, moving Codex from the non-system AppxVolume to the system AppxVolume was sufficient for Computer Use to reappear in Plugins and work successfully.

   ❤️React with ❤️1Reacted by wanger207
7. zemeng5208 commented on Aug 12, 2026

   

   zemeng5208

   on Aug 12, 2026 – with ChatGPT Codex Connector

   More actions

   I maintain WinBridge Recovery, an independent Windows recovery tool for Codex Desktop: https://github.com/zemeng5208/winbridge-recovery

   This issue is very close to one of the local failure classes the project is designed to diagnose. In v3.1.1, WinBridge already resolves the currently installed Store package, builds a user-writable verified resource mirror, uses byte-stream FileStream copying with SHA-256 verification, and checks the bundled marketplace / plugin cache / latest / CUA runtime / Native Host layers before deciding whether to repair anything.

   The Application Protected / EFS path is still explicitly Experimental in the project; I do not consider it a guaranteed fix yet. The newer AppxVolume finding in this thread is particularly useful: InstallLocation alone is not sufficient, so I am treating the actual AppxVolume association and protection state as an important diagnostic signal rather than assuming every C:\Program Files\WindowsApps\... path is equivalent.

   For machines where the failure is local relocation/cache/marketplace drift, WinBridge may be useful for diagnosis and safe staged recovery/rollback from the official package already installed on that machine. It does not modify WindowsApps ACLs/ownership, decrypt or patch the Store package, and it will not fix an upstream Computer Use runtime bug once the local runtime has been provisioned correctly.
8. MickeyWzt commented on Aug 15, 2026

   

   MickeyWzt

   on Aug 15, 2026

   More actions

   Additional physical-volume A/B evidence from an affected Windows 11 machine:

   • Get-AppxPackage reported the usual C:\Program Files\WindowsApps\OpenAI.Codex_<version>... install path, but that package directory was a junction whose physical target was D:\WindowsApps\OpenAI.Codex_<version>....
   • The Codex runtime/plugin destinations remained on C: under %LOCALAPPDATA%\OpenAI\Codex and %USERPROFILE%\.codex.
   • The failing copies had the same errno=-4094, code=UNKNOWN, syscall=copyfile, sourceKind=windowsapps signature described here. At the time, the Desktop package was on a 26.803 build while local bundled plugin/runtime material still contained 26.623 artifacts.
   • After moving the Store package back to the system AppX volume, the package directory became a physical C: directory rather than a junction to D:. The next Store update (26.810.6296.0 -> 26.810.7004.0) stayed physically on C: and the original cross-volume -4094 signature was no longer the active failure.

   This does not prove that all D-drive installations fail, or that cross-volume placement is required for the protected-file bug. It does confirm that a non-system AppX volume was a trigger in at least one reproducible environment and that returning the package to the system volume removed that trigger.

   I documented the complete two-layer postmortem (protected-file relocation plus a separate persisted-marketplace conflict exposed by the next Store update) here:

   https://gist.github.com/MickeyWzt/416bd69fa28b59c65aaec37aed9b34d1
9. Xyntel-632 commented on Aug 21, 2026

   

   Xyntel-632

   on Aug 21, 2026 – with ChatGPT Codex Connector

   Last edited by Xyntel-632

   More actions

   Reproduced on a newer Windows build, with the same protected-file/runtime relocation pattern and a much larger impact on startup responsiveness.

   Environment

   • ChatGPT/Codex Microsoft Store package: 26.818.3698.0
   • About dialog: 26.818.31338 (released Aug 21, 2026)
   • Windows 11 Home Single Language 25H2, build 26200.9168
   • Personal/unmanaged device

   AppxVolume / cross-volume correlation

   My packaged Codex resources are physically being accessed from D:\WindowsApps\OpenAI.Codex_..., while the per-user runtime destination is on C: under:

   C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node
   

   That appears consistent with the non-system AppxVolume / cross-volume pattern reported above in this thread.

   User-visible impact

   On this build, the problem is not limited to Computer Use being unavailable. The entire ChatGPT desktop app repeatedly becomes Not Responding during startup and can take roughly 40 minutes to become usable. Restarting often re-enters the same behavior.

   Windows Error Reporting logged:

   Event Name: AppHangTransient
   Process: ChatGPT.exe
   Timestamp: 2026-08-21 19:41:01 UTC
   

   WinDbg evidence

   I captured a full user-mode dump while ChatGPT.exe was actively hung. !analyze -hang reported:

   FAILURE_PROBLEM_CLASS: BlockedOn_FileIO
   IMAGE_NAME: chrome.dll
   

   Relevant stack:

   ntdll!NtCreateFile
   KERNELBASE!BaseCopyStream
   KERNELBASE!BasepCopyFileExW
   KERNELBASE!CopyFileExW
   KERNELBASE!CopyFileW
   chrome!uv_fs_open
   chrome!uv_fs_copyfile
   ...
   chrome!ChromeMain
   ChatGPT
   

   Inspecting the NtCreateFile parameters identified the blocked target as:

   C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\
   .staging-dd584937042db7da-<random>\bin\corepack
   

   Procmon reproduction

   Sysinternals Process Monitor independently captured the same operation:

   Process: ChatGPT.exe
   Operation: CreateFile
   Result: ACCESS DENIED
   Duration: ~20.0015 seconds
   Disposition: OverwriteIf
   

   The target was the same .staging-...\bin\corepack path. Multiple attempts showed the same ~20 second delay before ACCESS DENIED.

   I then renamed the existing local cua_node directory and let the app rebuild it from scratch. The behavior reproduced cleanly:

   1. a new .staging-dd584937042db7da-<random> directory was created;
   2. bin\corepack appeared at 0 KB;
   3. the partial staging contents were removed;
   4. another .staging-* attempt was created later with the same runtime ID and a different random suffix.

   Encryption / independent copy test

   cipher /c reports the bundled WindowsApps source corepack as encrypted:

   E corepack
   

   I also tested an elevated manual copy using:

   xcopy /G /Y "<WindowsApps Codex package>\app\resources\cua_node\bin\corepack" "%TEMP%\codex-efs-test\"
   

   Unlike the workaround reported in the original issue, /G does not succeed on this machine. It stalls for roughly two minutes, exits without the normal 1 File(s) copied confirmation, and no destination corepack is created.

   So on 26.818.3698.0, this still looks closely related to the protected/Application Protected runtime relocation issue, with a strong additional correlation to a non-system D: AppxVolume and with the impact now extending to repeated full-app startup hangs.

   I have preserved the full WinDbg dump, Procmon .PML, WER details, and sanitized screenshots if maintainers need additional diagnostics.

   ---

   Update: Confirmed mitigation and before/after results are documented here: #34764 (comment)
10. Xyntel-632 commented on Aug 22, 2026

    

    Xyntel-632

    on Aug 22, 2026 – with ChatGPT Codex Connector

    More actions

    Confirmed mitigation / before-after result

    Following the earlier findings in this thread, I moved only the OpenAI.Codex package from the non-system D: AppxVolume to the system C: AppxVolume using Windows' built-in Move-AppxPackage.

    Before the move

    • OpenAI.Codex was registered on D:\WindowsApps (IsSystemVolume=False).
    • The package files on D: were marked encrypted/protected.
    • ChatGPT Desktop routinely took 25–50+ minutes to start, frequently became Not Responding, or showed the crash screen.
    • WinDbg showed the hang inside CopyFileW / uv_fs_copyfile.
    • Procmon captured repeated ~20-second ACCESS DENIED failures while copying cua_node\...\bin\corepack.
    • Fresh launches repeatedly created incomplete .staging-dd584937042db7da-* runtime directories.

    Mitigation

    $pkg  = Get-AppxPackage OpenAI.Codex
    $cVol = Get-AppxVolume -Path C:\
    Move-AppxPackage -Package $pkg.PackageFullName -Volume $cVol

    The operation ultimately completed successfully. OpenAI.Codex_26.818.4152.0 is now registered on the system C: AppxVolume with Status: Ok, and no Codex package remains registered on the D: AppxVolume.

    After the move

    • First launch: usable window in approximately 10–15 seconds.
    • A fresh cua_node runtime directory was successfully created instead of another failed .staging-* directory.
    • bin\corepack was successfully deployed with a non-zero size (334 bytes).
    • Clean quit terminated the subprocesses immediately.
    • Second clean launch: window appeared in approximately 5 seconds and was fully usable within about 15 seconds, with no observed meaningful lag or freeze.
    • This test/reply was performed from the working Codex desktop app.

    This is strong before/after evidence that, on this machine, installation on the non-system AppxVolume was triggering the protected-file/runtime-copy failure, and moving the package to the system AppxVolume resolved it.

    OpenAI feedback/session ID for telemetry correlation:
    no-active-thread-01a02688-33dd-75d0-b392-ee91c8b003c6

    Current installed Codex package tested: 26.818.4152.0
    Windows 11 build: 26200.9168
11. ChenfeiXie commented on Sep 5, 2026

    

    ChenfeiXie

    on Sep 5, 2026

    More actions

    Additional reproduction on Codex Desktop 26.901.5280.0 (Windows, Microsoft Store/MSIX), with a specific observation about the encrypted-copy fallback.

    The bundled Browser manifest declares 26.901.41600 and the configuration references that version's scripts/browser-service.mjs, but the corresponding cache directory was absent. Startup logs show plugin_marketplace_folder_write_failed during copy_plugins, copying the bundled plugins/sites/.app.json into the marketplace staging directory. Similar failures were present across multiple app versions.

    Fallback condition appears not to match the actual error

    Inspecting the installed app's windows-file-copy-Dm31CRG0.js (read-only), the encrypted-copy fallback predicate requires error instanceof Error && error.errno === 6000. The observed Node error is instead:

    {"code":"UNKNOWN","errno":-4094,"syscall":"copyfile"}

    Independent tests against the same packaged .app.json:

    • cipher /c reports Encrypted / Application Protected.
    • A direct Win32 CopyFileW call fails with GetLastError() == 6000.
    • A standalone Node fs.copyFile call fails with UNKNOWN, errno: -4094, matching the desktop log. This test used the locally installed Node, not the app's embedded Electron runtime.
    • Reading the bytes and writing them to a new file succeeds, with identical content.
    • No windows_encrypted_copy_fallback_* messages were found in the examined September 5 desktop logs.

    This suggests that the existing stream-copy fallback is skipped because it checks the raw Win32 error number, while Node exposes a translated error. It would be useful to cover this error shape with a regression test, distinguishing an encryption-related UNKNOWN error from unrelated copy failures.

    Minimal Node reproduction

    Run against an affected Application Protected package file; substitute the actual package path:

    const fs = require('node:fs/promises');
    const path = require('node:path');
    const os = require('node:os');
    (async () => {
      const source = String.raw`C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\sites\.app.json`;
      const dir = await fs.mkdtemp(path.join(os.tmpdir(), 'codex-copy-repro-'));
      try {
        await fs.copyFile(source, path.join(dir, 'native.json'));
        console.log('native copy succeeded');
      } catch (error) {
        console.log({code: error.code, errno: error.errno,
          fallbackWouldRun: error instanceof Error && error.errno === 6000});
      }
      const bytes = await fs.readFile(source);
      await fs.writeFile(path.join(dir, 'bytes.json'), bytes);
      console.log('byte copy matches:', bytes.equals(await fs.readFile(path.join(dir, 'bytes.json'))));
    })();

    The reported C: package directory on this machine is a junction to D:\WindowsApps\..., which may be relevant to the AppxVolume observations above. Moving the package has not been tested here.

    Manually copying the current Browser plugin using data-only copying restored browser operation; all 382 source files matched SHA-256 hashes, and opening/reading a test page succeeded. This repairs the current cache, but does not fix the failing automatic marketplace synchronization. No installed application code, ACLs, or encryption policies were changed.
12. pyang1282-beep commented on Sep 6, 2026

    

    pyang1282-beep

    on Sep 6, 2026 – with ChatGPT Codex Connector

    More actions

    Additional affected build: 26.901.6511.0 — no startup window, many partial cua_node staging directories, eventual recovery

    Reporting observations from my Windows machine on 2026-09-06. This appears related to this issue's protected-file relocation problem and extends the startup-hang reports above to 26.901.6511.0.

    Environment

    • Windows 11 x64, Microsoft Store/MSIX installation.
    • Stable package: OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0; the executable/window is named ChatGPT.
    • Also installed: OpenAI.CodexBeta_26.727.4816.0_x64__2p2nqsd0c76g0, reported working during the investigation.
    • Reported stable install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0.
    • Actual AppxVolume registration/junction target was not verified in this investigation; the C: path alone should not be interpreted as proof of physical placement on the system volume.

    Observed startup state

    At about 12:52 local time (UTC+8), the stable app had main, GPU, network, storage and crash-handler processes, but:

    MainWindowHandle = 0
    renderer processes = 0
    codex.exe processes = 0
    

    No window or actionable error appeared. The main process's recorded start time was 12:50:19.

    The runtime cache under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node contained 22 .staging-b474a88d5d105afa-* directories. Their last-write times ranged from 12:07:01 to 12:50:41. At the 12:55 inspection, those directories contained 174–3,341 files each, versus 4,684 files / approximately 322 MiB in the packaged app\resources\cua_node source.

    Example sanitized snapshot:

    Staging suffix   Files   LastWriteTime (UTC+8)
    YFQiv9             241   12:07:01
    T11eE9             174   12:15:02
    0sYK6f            3341   12:43:17
    9As9Yf            2828   12:50:41
    

    Independent copy failure

    During the same investigation, reading/hashing the packaged cua_node\bin\node.exe succeeded, but copying that same file to %TEMP%\test-node.exe with PowerShell Copy-Item failed:

    无法加密指定的文件。
    The specified file could not be encrypted.
    

    These are the operations used (user paths replaced with environment variables):

    $pkg = (Get-AppxPackage -Name OpenAI.Codex).InstallLocation
    $source = Join-Path $pkg 'app\resources\cua_node\bin\node.exe'
    Get-FileHash -LiteralPath $source -Algorithm MD5
    # Succeeded
    Copy-Item -LiteralPath $source -Destination (Join-Path $env:TEMP 'test-node.exe') -Force -ErrorAction Stop
    # Failed with the encryption message above

    The recorded copy test did not print a numeric HRESULT/Win32 code, so I am not treating error 6000 as independently captured in this specific test.

    Eventual recovery and timing limits

    The app subsequently opened during the investigation. At 13:01:06, inspection confirmed:

    renderer processes = 3
    codex.exe processes = 1
    main window title = ChatGPT
    MainWindowHandle != 0
    cua_node cache listing = b474a88d5d105afa
    cache directory LastWriteTime = 12:57:53
    

    The prior staging directories no longer appeared in that final cache listing. This is roughly 51 minutes between the earliest staging timestamp and the final directory timestamp, with a working window confirmed afterward. It is not a measured 50-minute lifetime of one process: the observed main process started at 12:50:19. The directory snapshots do not establish whether earlier attempts were automatic retries, separate launches, or a mixture. They also do not establish why the eventual attempt succeeded, or guarantee that waiting will recover other launches.

    Expected behavior / investigation request

    The app should show usable startup UI promptly, or surface the underlying relocation error with a bounded retry policy. Please investigate the protected-source copy path and handling/reuse/cleanup of partial runtime staging directories.

    The successful read plus failed copy is consistent with the encryption-related copy problem already reported here, but these observations alone do not prove the exact internal cause of every partial copy or the later recovery. A decrypted-destination/byte-copy fallback and a regression test for the actual Node error shape described in the preceding comment seem worth checking.

    Related relocation reports: #38696 and #40700.
13. wmdl2 commented on Sep 7, 2026

    

    wmdl2

    on Sep 7, 2026

    Last edited by wmdl2

    More actions

    This report was prepared with AI assistance. The copy test results and log observations below are distinguished from the proposed root cause, which has not been confirmed by a maintainer.

    Additional reproduction on Codex Desktop Windows 26.901.6511.0 (bundled CLI 0.153.4), Windows 11 x64 build 26200.

    The bundled plugin materialization failure still reproduces on startup:

    plugin_marketplace_folder_write_failed
    errorCode=UNKNOWN
    copyfile '<WindowsApps>/OpenAI.Codex_26.901.6511.0_x64__<publisher>/app/resources/plugins/openai-bundled/plugins/sites/.app.json'
      -> '<CODEX_HOME>/.tmp/bundled-marketplaces/openai-bundled.staging-<id>/plugins/sites/.app.json'
    bundled_plugins_marketplace_resolve_failed
    

    Copy comparison and a possible fallback predicate bug

    For the same packaged sites/.app.json (105 bytes, Windows attributes Archive, Encrypted), copying into a writable workspace directory produced:

    • Win32 CopyFileW: failed; GetLastError() = 6000 (ERROR_ENCRYPTION_FAILED).
    • Bundled Node fs.copyFileSync: failed; code = "UNKNOWN", errno = -4094, syscall = "copyfile".
    • Reading source bytes and writing a new destination file: succeeded.

    Read-only inspection of the installed windows-file-copy-Dm31CRG0.js shows that the existing stream-copy fallback is gated on error instanceof Error && error.errno === 6000. It appears the Node error mapping prevents that fallback from being selected for this case. No windows_encrypted_copy_fallback entries appeared in the inspected Desktop startup log.

    The bundled marketplace copy uses Promise.all across plugins, and the sites copy rejection propagates to the marketplace resolution failure. This affects more than the individual failing plugin.

    The error comparison above was reproduced with the bundled Node executable, not by instrumenting Electron's live exception object; the Desktop logs independently show the same UNKNOWN copy failure. Please verify the mapping in Electron as well before changing the predicate. A narrowly scoped encrypted-source fallback would be preferable to treating every UNKNOWN error as an encryption failure.

    Current scope

    node_repl reports ready and responds to calls, and the configured Computer Use native pipe exists with a startup ready log. Plugin materialization remains the blocker under investigation. Separately, a missing bundled @oai/sky tslib fragment in the relocated runtime was restored from the identical installed runtime version and its hash verified; @oai/sky then imported successfully. This did not resolve the plugin copy failure.

    As a manual troubleshooting experiment, a byte-for-byte workspace copy of all 849 bundled plugin files was created; it passed SHA-256 checks and a complete Node fs.cp test. Trying the source-visible CODEX_ELECTRON_BUNDLED_PLUGINS_RESOURCES_PATH process environment override did not change the source used by the packaged Desktop after launch, so this experiment did not resolve the issue. This manual copy and environment override should not be interpreted as a routine setup step or an officially supported repair.

    During this investigation, we did not modify WindowsApps source files, ACLs, Windows protection settings, or marketplace registration. This statement is limited to the actions performed during this investigation, not the machine's prior history. Usernames and machine-specific paths are redacted here.
14. Ink-Paper commented on Sep 19, 2026

    

    Ink-Paper

    on Sep 19, 2026 – with ChatGPT Codex Connector

    More actions

    Additional reproduction on ChatGPT/Codex Windows package 26.915.4065.0, bundled Chrome plugin 26.915.31945, tested bundled Node v24.21.0. This adds current-version confirmation, Chrome side-panel impact, and a test of the installed fallback helper itself to the earlier findings in this issue.

    This report was prepared with AI assistance. The measurements below were reproduced locally; the desktop-process explanation is based on logs and read-only inspection, not confirmation by a maintainer.

    Chrome side-panel impact after updates

    The side panel reports:

    No compatible Codex app-server entry was found
    

    An earlier occurrence reported a missing required nodePath. Native messaging uses the official per-package Windows app execution alias, but both chrome-native-hosts-v2.json files retain superseded package/runtime paths. The materialized bundled marketplace remains at 26.810.41047.

    Desktop logs on 2026-09-19 show:

    plugin_marketplace_folder_write_failed
    folderWritePhase=copy_plugins
    errorCode=UNKNOWN
    copyfile '<WindowsApps>/OpenAI.Codex_<version>/app/resources/plugins/openai-bundled/plugins/browser/.codex-plugin/plugin.json'
      -> '<CODEX_HOME>/.tmp/bundled-marketplaces/openai-bundled.staging-<id>/plugins/browser/.codex-plugin/plugin.json'
    bundled_plugins_marketplace_resolve_failed
    

    Independently measured copy behavior

    For the same encrypted bundled source file:

    Operation	Result
    Win32 CopyFileW	GetLastError = 6000, ERROR_ENCRYPTION_FAILED
    CopyFileExW, default flags	6000
    CopyFileExW, COPY_FILE_ALLOW_DECRYPTED_DESTINATION (0x8)	Success; SHA-256 matches
    Node fs.copyFile / fs.cp	UNKNOWN / errno -4094
    Read/write stream copy	Success; SHA-256 matches
    Ordinary Node copy of the unencrypted byte-identical copy	Success

    EFS is enabled and running. Same-volume, cross-volume and physical-source-path tests reproduced the failure. The package is physically on D: with a registered C: WindowsApps junction; this is not a claim that moving the package via AppX deployment would fail—we have not tested that workaround.

    Installed helper and complete-bundle test

    The shipped windows-file-copy-B0DNtkPq.js enables its stream fallback only when error.errno === 6000.

    An isolated harness loaded that installed helper unchanged:

    1. A real fs.cp callback failed with -4094; no fallback event occurred.
    2. In a second test, only inside the test callback, that observed error was mapped to the independently measured Win32 value 6000.
    3. The installed helper then emitted windows_encrypted_copy_fallback_started and windows_encrypted_copy_fallback_succeeded.
    4. The entire bundled marketplace—822 files, 85,382,574 bytes—copied successfully.
    5. A second normal recursive copy also succeeded. Both copies had identical file lists and per-file SHA-256 hashes to the original, with zero mismatches.

    This was standalone Node, not injected into the running Electron process. It validates the complete copy stage, not end-to-end desktop synchronization.

    Why registration remains stale

    Read-only control-flow inspection shows marketplace materialization failure returns hadReconcileFailure: true before later plugin/version reconciliation and Chrome native-host registration. The Chrome CLI/runtime staging path also uses the same copy helper.

    A local manifest repair restored native-host hello/ensure and WebSocket app-server initialize, but it does not fix the next update. No app binaries, ACLs, certificates or encryption policies were modified, and no scheduled repair task was installed.

    Please verify the Node/Electron error mapping and enable the existing fallback for verified encrypted bundled resources (or use CopyFileExW with the decrypted-destination flag), while preserving errors for unrelated UNKNOWN failures. Regression coverage should include full marketplace copy, CLI staging, plugin reconciliation and Chrome manifest refresh across an app upgrade.

    Related Chrome registration symptoms: #42520.