Skip to content

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

Open
Open
[Feedback][macOS] /feedback shows task ID as ready, then diagnostics upload fails#39892
Labels
appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

Description

@omarpinarecords
omarpinarecords
opened on Aug 21, 2026

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

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Aug 21, 2026

  2. nos1609 commented on Aug 25, 2026

    @nos1609
    nos1609
    on Aug 25, 2026 – with ChatGPT Codex Connector

    Independent Windows ARM64 confirmation on the same current Desktop release family.

    Environment:

    • Microsoft Store package: 26.818.8289.0
    • Desktop release: 26.818.61809
    • Correlation task ID: 019f3421-934e-7471-8c1b-95c95f668565

    Two in-app feedback submissions from the affected task did not produce a durable final success receipt.

    A read-only check after the attempts found:

    • no final successful-upload receipt in the local app logs;
    • no durable retry object;
    • the Sentry queue was empty.

    An empty queue does not prove success. It can also mean that the failed report was dropped before durable queuing. Therefore the user still cannot determine whether the feedback text reached the backend, only diagnostics failed, or nothing was accepted.

    This reproduces the core ambiguity described here on Windows ARM64. The UI needs separate durable status for the base feedback payload and diagnostics, plus a stable server-issued receipt after acceptance.

    Privacy: no feedback text, logs, local paths, account data, hostnames, or project names are included.

  3. aidawilliam41-ops commented on Aug 30, 2026

    @aidawilliam41-ops
    aidawilliam41-ops
    on Aug 30, 2026 – with ChatGPT Codex Connector

    Windows x64 reproduction: Sentry upload timeouts with request IDs

    OpenAI Support asked me to add the two application request IDs and a sanitized log excerpt so engineering can correlate this Windows reproduction.

    Environment:

    • Microsoft Store package: 26.818.5229.0
    • Embedded app-server: 0.149.0-alpha.4.1
    • Windows 11 Pro 25H2 x64, build 26200.8037
    • Time zone: Europe/Moscow, UTC+3

    Sanitized evidence:

    2026-08-22 10:19:04.326 +03
method=feedback/upload
durationMs=27538
errorCode=-32603
requestId=ab88e893-3cea-437d-a97a-0f0a5e789c37
error="failed to upload feedback to Sentry: route-aware request timed out"

2026-08-22 10:21:28.125 +03
method=feedback/upload
durationMs=15492
errorCode=-32603
requestId=bf234c76-6dd8-4e2f-9e79-0dd65094f2cf
error="failed to upload feedback to Sentry: operation timed out"

    Successful upload acknowledgements: 0.

    Normal PNG uploads and authenticated Codex account/configuration requests succeeded during the same session. A later read-only check confirmed working DNS, TCP 443, and TLS connectivity to the Sentry host in about 1.6 seconds. No WinHTTP, WinINET, PAC, environment, or system proxy was configured. The feedback POST was not repeated because delivery status was unknown and retry idempotency was not documented.

    No third-party antivirus HTTPS scanning or Web Shield was known to be enabled. A current read-only check found no installed/running third-party antivirus or Web Shield and no common HTTPS-inspection root certificate. A historical per-feature antivirus toggle for the exact event minute cannot be proven.

    The UI displayed:

    • Не удалось отправить отзыв.
    • Не удалось отправить отзыв, но его идентификатор остался прежним.

    The displayed identifier matched the originating Codex task ID; it was not an independently confirmed feedback receipt. Delivery remains unknown.

    Privacy: no account/email data, private conversation content, local paths, raw logs, or support case number are included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions