›_ Codex Issues
Codex Issues / #28258

Windows Codex Desktop repeatedly creates cua_node .staging runtime directories under mojibake Chinese user path, filling disk

Resolved 💬 6 comments Opened Jun 15, 2026 by henryshenghw-sys Closed Jun 24, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment:

  • OS: Windows
  • Codex Desktop package: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
  • Windows user profile contains Chinese characters: C:\Users\<ChineseUser>
  • Codex app runs Windows-native / PowerShell agent

Issue:
Codex Desktop repeatedly creates full runtime staging directories for cua_node under a mojibake path derived from the Chinese username.

Bad path observed:
C:\Users\<mojibake-ChineseUser>AppData\Local\OpenAI\Codex\runtimes\cua_node

In my case the path looked like:
C:\Users\LBX_XXB_鐩涘畯浼焅AppData\Local\OpenAI\Codex\runtimes\cua_node

Observed behavior:

  • Codex repeatedly creates directories named .staging-789504f803e82e2b-*
  • Each staging directory is about 272 MB
  • It accumulated 70 staging directories again, about 19 GB
  • Previously it accumulated hundreds of staging directories and filled the disk
  • The completed runtime directory 789504f803e82e2b already exists
  • Codex still attempts to create new staging directories

Expected behavior:

  • Codex should use the correct Unicode user profile path:

C:\Users\<ChineseUser>\AppData\Local\OpenAI\Codex

  • Runtime installation should complete once and not leave repeated .staging directories
  • It should not repeatedly download/extract cua_node when the runtime already exists

Evidence:

  • Final runtime dir exists: 789504f803e82e2b
  • Staging count reached 70
  • Runtime staging consumed about 19 GB
  • Workaround applied locally: deny WriteData/AddFile and AppendData/AddSubdirectory on the cua_node parent directory to stop disk growth

Impact:
This can rapidly fill both C: or any redirected target disk on Windows machines with non-ASCII user profile paths.

Notes:
codex doctor could not be run from the WindowsApps package path due to Access is denied.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #28093
  • #28079
  • #28017
  • #28245

Powered by Codex Action

yyf325418-del · 1 month ago

你好，请问一下这个怎么解决

MasterOK1975 · 1 month ago

I’m seeing the same issue on Windows with a Cyrillic / non-ASCII Windows username.

In-app feedback ID:
019e7d35-863a-7563-87e5-b0353185ca70

My case looks very similar to this issue:

  • Codex creates many .staging-* folders under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

  • Each .staging-* folder is about 272 MB.
  • Opening a chat for the first time in the current Codex session creates more staging folders.
  • Reopening an already loaded chat does not increase disk usage.
  • The staging folders are not cleaned up automatically.

Current impact:

  • Runtime folder reached 26.5 GB / 27.1 GB on disk
  • 341,600 files
  • 65,501 folders
  • 100+ .staging-* folders visible

My Windows user profile path contains Cyrillic characters and appears as mojibake in Explorer / terminal output.

Question:
Is the current recommended workaround still to deny WriteData/AddFile and AppendData/AddSubdirectory on the cua_node parent directory, or is there a safer workaround now?

Related:
#28691
#28093
#28017

Z1WZ05 · 1 month ago

how to solve it?

MasterOK1975 · 1 month ago

Update from my side:

After updating Codex Desktop to 26.616.5445.0, the issue appears to be resolved for me.

Previously, Codex repeatedly created .staging-* folders under cua_node, and the runtime folder grew to tens of GB.

Now, after opening/switching multiple chats:

  • .staging-* folders no longer accumulate
  • disk usage may temporarily increase, but returns back to normal
  • current .staging-* count is 0

In-app feedback ID:
019e7d35-863a-7563-87e5-b0353185ca70

henryshenghw-sys · 27 days ago

Update from my local environment:

After updating Codex Desktop to 26.616.9593.0, the issue no longer appears to reproduce on my machine.

Current status:

  • The correct Unicode runtime path is now being used:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

  • There are currently 0 .staging-* directories under the correct cua_node path.
  • The runtime directory contains one normal runtime folder, about 285 MB.
  • The old mojibake path still exists as a leftover directory, but it is no longer growing.
  • The old mojibake cua_node directory contains only one completed runtime folder, about 272 MB, and 0 .staging-* folders.
  • I still have the previous Deny ACL workaround applied only on the old mojibake cua_node path.
  • I did not apply the Deny ACL workaround to the correct Unicode path.

So for my local setup, the current practical solution is:

  1. Update Codex Desktop to a newer version, currently 26.616.9593.0.
  2. Verify that Codex is using the correct Unicode %LOCALAPPDATA% path.
  3. Confirm that .staging-* folders are no longer accumulating.
  4. Keep or remove the old mojibake-path ACL workaround only after confirming the issue does not return.
  5. Optionally clean up the old mojibake runtime directory once it is confirmed to be unused.

Based on this, the safer workaround now seems to be updating Codex Desktop first, rather than relying on the Deny ACL workaround as the primary fix.