Performance trace upload timeout does not retain local trace artifact

Open 💬 1 comment Opened May 23, 2026 by MisterRound

Summary

A Codex Desktop performance trace was recorded for a long stalled Thinking turn. When stopping the trace, upload timed out. The log recorded a local trace path, but after the upload timeout the trace artifact was not recoverable at that path or in the nearby expected locations.

This means the diagnostic artifact for a reproduced stall was lost exactly when it was needed.

Environment

  • Product: Codex Desktop on Windows 11
  • Desktop package observed in logs: OpenAI.Codex_26.519.5221.0
  • Desktop release string observed in logs: 26.519.41501
  • WSL app-server binary: codex-cli 0.130.0-alpha.5
  • Trace started from the Desktop UI Help menu
  • Related stall issue from the same capture session: #24260

What happened

A performance trace was started while a Codex Desktop thread was stuck on Thinking. The trace ran long enough to cover the latter part of a 30m+ pre-first-output stall and the moment when the turn finally began emitting assistant output.

Relevant sanitized log lines:

2026-05-23T16:24:23.298Z info [content-tracing] Started content trace recording.
2026-05-23T18:54:07.689Z info [content-tracing] Stopped content trace recording. recordingDurationMs=8984391 tracePath=%LOCALAPPDATA%\Temp\codex-trace-<id>.json
2026-05-23T18:59:00.835Z warning [content-tracing] Failed to toggle content trace recording. errorMessage="Trace upload timed out" errorName=Error errorStack="Error: Trace upload timed out ... trace-recording-sentry-upload-...js ..."

recordingDurationMs=8984391 is about 2h29m44s.

Actual behavior

After the upload timed out:

  • The logged %LOCALAPPDATA%\Temp\codex-trace-<id>.json file was not present.
  • No matching codex-trace file was found under %LOCALAPPDATA%\Temp.
  • No trace-like artifact was found in common user locations such as Downloads/Desktop/Documents.
  • The Codex Sentry queue/cache did not appear to contain the trace.

I am wording this conservatively as “not retained/recoverable” rather than claiming a specific delete path, but from the user perspective the trace disappeared after upload failure.

Expected behavior

If trace upload fails or times out, Codex Desktop should retain the local trace artifact and make it recoverable. At minimum it should:

  • keep the file until upload succeeds, or
  • move it to a stable diagnostics folder, or
  • show the user a local path and retry/save option, or
  • queue the upload durably without deleting the only local copy.

Why this matters

The trace was intentionally recorded to capture a difficult intermittent stall. Losing it after upload timeout prevents the user from attaching or preserving the main diagnostic artifact. The fallback behavior should be biased toward preserving evidence, especially for performance traces.

Related context

The trace overlapped with a gpt-5.5/xhigh turn that stalled for more than 30 minutes before first output: #24260.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗