[Bug][Windows] Stale responses-state atomic-write temp files accumulate indefinitely #499

Client or integration

OpenCodex proxy state persistence (observed while using Codex App)

Area

Proxy and routing

Summary

On OpenCodex 2.7.40 on Windows, stale atomic-write temporary files for responses-state.json accumulated indefinitely under the OpenCodex config directory:

• pattern: responses-state.json.ocx.<pid>.<sequence>.tmp
• count: 263 files
• total size: 5.88 GB
• creation period: July 20–25, 2026
• all PIDs encoded in the stale filenames were no longer running

I expected interrupted/failed response-state writes to be cleaned up, either during the failed write or on a later proxy startup. Instead, crash/forced-termination remnants survived multiple restarts and consumed several gigabytes.

This report is about unbounded stale state files and disk/privacy hygiene. I am not claiming that their mere presence was the primary cause of dashboard latency; a separate issue reports the independently measured usage.jsonl performance problem.

Reproduction

The exact interruption timing has not yet been reduced to a deterministic single command. The production observation followed several proxy crashes or forced terminations while responses-state.json was large and actively persisted.

A likely reproduction path is:

1. Use Responses/Codex conversations long enough for responses-state.json to grow substantially.
2. Terminate the proxy while the debounced response-state snapshot is being persisted.
3. Restart and repeat.
4. Inspect the OpenCodex config directory for stale files:

$home = Join-Path $HOME '.opencodex'
$tmp = Get-ChildItem -LiteralPath $home -File -Filter 'responses-state.json.ocx.*.tmp'
$tmp | Measure-Object Length -Sum
$tmp | Select-Object Name, Length, LastWriteTime

Observed filename PIDs were:

3200, 6400, 6664, 10168, 15772, 17400, 32660

None were alive when checked. The newly restarted proxy PID did not occur in any stale filename.

Cleanup observation, without asserting a root cause: PowerShell Remove-Item, Copy-Item, and Rename-Item returned access denied for sampled stale files, while [System.IO.File]::Delete() succeeded. File owner/attributes alone did not explain the difference, so this should be treated only as an observed Windows cleanup behavior.

Implementation notes

In 2.7.40:

• src/responses/state.ts:136-164 serializes the response-state snapshot and calls atomicWriteFile(...) from a best-effort try/catch.
• src/config.ts:80-125 creates ${path}.ocx.${process.pid}.${sequence}.tmp and attempts truncate/unlink cleanup on ordinary exceptions.
• An abrupt process termination can bypass that cleanup path.
• persistNow() swallows disk failures because the snapshot is a cache, so a cleanup failure may leave no durable diagnostic.
• I did not find a startup sweep/doctor check for stale responses-state.json.ocx.*.tmp files.

The temporary files can contain persisted conversation response state, so accumulation is also undesirable from a data-retention perspective even when file permissions are hardened.

Expected behavior

Please consider:

1. Cleaning stale atomic-write temp files on startup using a strict basename pattern, minimum age/grace period, and live-PID protection.
2. Keeping normal exception cleanup, but adding recovery for abrupt termination leftovers.
3. Reporting stale temp count/bytes in ocx doctor or the Storage page.
4. Ensuring cleanup never touches the active write or unrelated .tmp files.
5. Adding a regression test that leaves a fixture temp file from a dead PID and verifies bounded startup recovery.

Version

@bitkyc08/opencodex 2.7.40

Operating system

Windows NT build 10.0.26200.8875 (x64)

Provider and model

Not provider-specific.

Logs or error output

Before cleanup:
  stale files: 263
  total size: 5.88 GB
  active-PID conflicts: 0

After bounded manual cleanup:
  stale files: 0
  disk space recovered: approximately 5.88 GB

Redacted configuration

Not configuration-specific.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.