[Feedback][macOS] /feedback shows task ID as ready, then diagnostics upload fails

Summary

In the current unified ChatGPT desktop app on macOS, the Codex task /feedback flow reaches a partial-looking state and then fails:

1. The dialog says Uploading feedback.
2. It says: “Your Feedback ID is ready while diagnostics finish uploading.”
3. It displays 01a02352-42e0-7db0-a2eb-c68dba704dd2.
4. That value exactly matches the current Codex task ID.
5. The app then shows: “We couldn't submit your feedback. Please try again in a moment.”

This leaves the submission state ambiguous. The UI presents an identifier as ready, but it does not establish whether the feedback text was accepted, whether only diagnostics failed, or whether the entire submission failed.

Environment

• Product surface: unified ChatGPT desktop app → Codex task
• Platform: macOS
• Subscription: ChatGPT Pro
• Date reproduced: 2026-08-21
• Client identifier observed in the same current task context: Codex Desktop/26.818.31338
• Correlation/current task ID: 01a02352-42e0-7db0-a2eb-c68dba704dd2

Steps to reproduce

1. Open a Codex task in the ChatGPT desktop app.
2. Run /feedback.
3. Enter feedback and submit it with diagnostics enabled.
4. Observe the Uploading feedback dialog.
5. Observe that the dialog presents the current Codex task ID as the Feedback ID while diagnostics continue uploading.
6. Wait for completion.
7. Observe the red error banner: “We couldn't submit your feedback. Please try again in a moment.”

After the failure, I also created a local performance trace to preserve diagnostic evidence. The app displayed the Send profile trace? warning that enabled JavaScript and native memory-allocation profiles may contain sensitive data. The trace was not uploaded or attached to this public issue.

Actual behavior

• The UI presents a Feedback ID before the upload finishes.
• The displayed value is the current Codex task ID, so it is not an independent success receipt.
• The flow later reports submission failure.
• The app does not say whether:
  • the feedback text was stored;
  • only diagnostics or extra files failed;
  • the report is queued for retry; or
  • nothing was accepted.
• There is no final auditable success state or separate diagnostic-upload status.

Expected behavior

• /feedback should complete successfully and show a final confirmation.
• If the base feedback report succeeds but diagnostics fail, preserve the base report and clearly state feedback submitted; diagnostics failed.
• If the entire submission fails, do not present the task/conversation ID as though it were a completed Feedback ID.
• Expose separate status for:
  • feedback text;
  • standard logs/diagnostics; and
  • optional performance/profile traces or extra files.
• Provide a retry path for only the failed diagnostic component without creating an uncertain duplicate report.

Impact

Users cannot tell whether OpenAI received their feedback. Retrying may create duplicates if the text succeeded, while not retrying may leave the report unsubmitted. The failure is especially problematic when /feedback is the recommended route for supplying diagnostics about another product defect.

The feedback that triggered this reproduction concerns the web Chat/Work Project-picker parity issue documented in #39884.

Related issue / duplicate distinction

• #16304 reports the same final error message on an older desktop build and says it can occur with or without logs.
• This report adds the current identifier-first, diagnostics-still-uploading, then failure sequence, proves that the displayed “Feedback ID” equals the current Codex task ID, and requests separate base-report and diagnostic-upload status.
• #39884 is the distinct product issue that the failed feedback submission was attempting to report.

Source basis

Official OpenAI documentation describes:

• /feedback as opening the feedback dialog and optionally including logs.
• feedback/upload as submitting classification, optional reason/logs, the conversation ID, and optional extra log-file attachments.

That product shape is consistent with the need to distinguish the base report from optional diagnostic uploads, but it does not establish which component failed in this reproduction.

Routing and privacy

• Type: bug / validation gap
• Scope: public OpenAI/Codex
• Owning surface: ChatGPT desktop app → Codex task
• Target repo: openai/codex
• Privacy class: public-safe, pointer-only diagnostics
• Excluded: raw performance trace, JavaScript/native memory profiles, logs, account details, Project names, local paths, and private conversation content
• Duty verbs: submit, upload, preserve, distinguish, retry
• Priority: P2
• Owner: OpenAI Codex desktop feedback pipeline
• Next safe action: reproduce the post-ID diagnostics failure and inspect server-side handling for the correlation/task ID above
• Approval gate: owner approved this sanitized public issue
• Validation/close criteria: final success is explicit; partial failures identify the failed component; base feedback is preserved when optional diagnostics fail; retrying diagnostics does not create duplicate feedback reports

Start by reproducing the /feedback flow in the macOS desktop app with diagnostics enabled, focusing on the identifier-first state and subsequent failure. Trace the feedback text, standard diagnostics, and optional trace uploads separately using the task ID described in the issue. Done means the UI gives an explicit final result, preserves successful base feedback, identifies partial failures, and retries failed diagnostics without duplicates.