[Bug][Windows] Test runner leaks thousands of TEMP directories and can trigger ProfSvc logon delays #4762

Client or integration

Other — repository test runner

Area

Platform (Windows / macOS / Linux)

Summary

On Windows, OpenCodex tests create opencodex-test-* and ocx-* directories directly beneath the user's TEMP directory. A completely successful test run can leave an opencodex-test-* tree behind, while numerous fixtures either do not clean their ocx-* directories or suppress exhausted cleanup failures.

Repeated test runs accumulated at least 9,272 attributable OpenCodex top-level directories on one workstation. Windows ProfSvc then spent approximately 15–21 seconds processing the user profile during logon. After the accumulated test TEMP tree was quarantined, logon returned to approximately 3 seconds.

The test isolation environment sets HOME, USERPROFILE, OPENCODEX_HOME, and CODEX_HOME, but does not redirect TEMP, TMP, or TMPDIR into the owned test root. Expected behavior is that all test-created temporary files are contained beneath one owned root and removed after successful, failed, and interrupted runs, with ownership-safe recovery of stale roots.

Reproduction

1. On Windows, create a disposable scratch directory outside the normal user TEMP directory.

2. In the reproduction shell only, set TEMP and TMP to that scratch directory.

3. Record the scratch directory contents.

4. Run:

   bun run test tests/lib/strict-semver.test.ts

5. Confirm that all tests pass.

6. Inspect the scratch directory after Bun exits.

Observed with Bun 1.4.2: the test completes with 7 passed and 0 failed, but one opencodex-test-* directory remains.

Repeated full-suite runs additionally create many sibling ocx-* directories. Forced termination, timeouts, open handles, antivirus/indexer locks, and other transient Windows file locks increase the residue, but they are not required to reproduce the bug.

Source observations:

• scripts/test.ts creates an opencodex-test-* wrapper root and sets HOME-related variables, but not TEMP/TMP/TMPDIR.
• tests/preload.ts creates another isolation root and relies on best-effort process.on("exit") removal.
• tests/helpers/isolated-codex-home.ts creates direct ocx-* roots and intentionally suppresses cleanup errors after retries.
• v2.51.0 contains 870 direct mkdtempSync(join(tmpdir(), ...)) calls across 465 files. Current dev contains 935 across 515 files.

The minimal containment fix appears to be:

1. Create a temp subtree inside the owned test-run root.
2. Set TEMP, TMP, and TMPDIR to that subtree before spawning test children.
3. Have the preload inherit it so direct os.tmpdir() fixtures become descendants of the owned root.
4. Add a strict, versioned ownership marker.
5. Remove the complete owned root with bounded retries and visible deferred-cleanup reporting.
6. Reclaim only stale, marker-owned roots on a later invocation.

A Bun 1.4.2 probe confirmed that changing TEMP/TMP after importing tmpdir changes the returned directory, so cached temp-path behavior does not block containment.

Version

Reproduced on v2.51.0 (c155cc7923dbc0102e27d79185505a85d4357b2c). The relevant scripts/test.ts behavior is unchanged on v2.56.0 and current dev; current dev has more direct TEMP producers.

Historical introduction appears to span:

• v2.7.35: outer opencodex-test-* root
• v2.8.0: preload-created second root
• v2.13.0: retry cleanup helper
• v2.24.2: exhausted cleanup is deliberately suppressed

Operating system

Windows 11, NTFS user profile, Bun 1.4.2

Provider and model

Not provider- or model-specific.

Logs or error output

Focused reproduction:
7 pass
0 fail
1 opencodex-test-* tree remains after process exit

Two Windows user-profile ETL captures each contained:
7,684 matching ActivityError events
7,424 x 0x80070005
260 x 0x800701C0

Relevant trace context:
profsvc.dll
CUserProfile_Load
SetReserveAreaOnFileTree
onecore\drivers\storage\storsvc\storagereserve\storagereserveinternal.cpp

The ETLs establish recursive profile processing during the delay but do not independently name individual TEMP child directories. Attribution rests on the combined evidence: exact OpenCodex producer names, matching accumulated directory families, a green-run reproduction, repeated-run counts, and the logon timing improvement after quarantine.

This is the same class of Windows impact reported in OpenCode #27005 and in a Microsoft support case where an oversized Local Temp directory delayed User Profile Service logon. Neither is an OpenCodex duplicate.

Screenshots and supporting files

Available privately if maintainers need them:

• Pre- and post-reserved-storage ETLs
• Decoded event summaries
• Quarantine prefix inventory
• Safe redirected-TEMP reproduction results

No existing OpenCodex issue was found for this defect. Issue #499 and PR #502 concern a different abandoned temporary-file class, but provide a useful ownership-safe recovery precedent.

Redacted configuration

{
  "providerSpecific": false,
  "providerConfigurationRequired": false
}

Checks

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

_{assisted by Sol/high}