Performance trace upload timeout does not retain local trace artifact

[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: Codex Desktop: gpt-5.5 xhigh turn stalled 30m before first output, then resumed normally #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.

[MisterRound]

Additional local log evidence confirms the trace was recorded, then lost after upload failure:

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

The stopped trace duration was about 2h29m44s. After the timeout, the referenced %LOCALAPPDATA%\Temp\codex-trace-<id>.json file was no longer present, and the local Sentry queue file was empty (queue-v2.json contained []).

This suggests the current trace-stop flow can create a local trace file, attempt upload synchronously, time out, and leave no recoverable artifact for the user or support. Suggested fix: on upload failure, keep the trace file and surface its local path in the UI/logs, or move it to a stable diagnostics folder and retry upload asynchronously.