codex - 💡(How to fix) Fix Possible infinite disk write / storage corruption behavior in Windows Codex app

What version of the Codex App are you using (From “About Codex” dialog)?

Codex 26.513.40821

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Environment:

• OS: Windows 11
• Codex Windows app (GUI version)
• Local development environment with Git LFS and Python tooling installed

What steps can reproduce the bug?

What happened: While using Codex for a coding task, I observed extremely heavy disk write activity that rapidly filled my C: drive.

At the time:

• Git LFS processes appeared active
• Disk usage increased continuously
• Network usage was minimal or near zero
• This suggests the issue may not have been normal downloading behavior

Later, after deleting the related project folder, disk space usage still did not match expectations.

I investigated further and found:

• C:\$Extend\$Deleted appeared to consume hundreds of GB
• The folder was inaccessible normally
• After rebooting Windows, the storage usage suddenly disappeared/reset

This makes me suspect:

• Possible runaway temporary writes
• Infinite/repeated write loop
• NTFS metadata or deleted-file handling interaction
• Background Codex/runtime process not releasing handles correctly
• Git LFS interaction bug
• Possible sandbox/runtime cleanup failure

Additional observation: During another task, Codex appeared to hang indefinitely while running a DuckDB/parquet-related Python command.

The command was similar to:

import duckdb, tempfile, pathlib
d=tempfile.TemporaryDirectory(dir=r'C:\tmp')
p=pathlib.Path(d.name)/'x.parquet'
con=duckdb.connect(':memory:')
con.execute('create table t as select 1 as a')
con.execute('copy t to ? (format parquet)', [str(p)])
print(p.exists(), con.execute('select count(*) from read_parquet(?)', [str(p)]).fetchone())
con.close()
d.cleanup()

Actual behavior:

• Massive unexplained disk usage growth
• Extremely heavy disk writes
• Storage not reclaimed immediately even after deleting project files
• NTFS $Extend\$Deleted growth
• Required reboot before storage recovered

What is the expected behavior?

Expected behavior:

• Temporary/runtime files should be cleaned correctly
• Disk usage should remain bounded
• Background processes should not continuously write data indefinitely
• Failed/hung tasks should not leave massive hidden filesystem artifacts

Additional information

Possible areas worth investigating:

• Runtime sandbox cleanup
• Git LFS integration
• Logging/tracing loops
• Temporary file lifecycle
• Windows NTFS interaction
• Background worker shutdown behavior