[Feedback Platform] Add an OpenAI-native issue tracker and official reporting app/plugin with trackable cases

Summary

OpenAI should provide a first-party issue-reporting system for OpenAI products, available directly inside ChatGPT as an official app/plugin or native command, with the same basic issue-management capabilities that ChatGPT currently has when connected to GitHub.

Today, reporting a product bug or feature request is fragmented across multiple unrelated surfaces:

• thumbs up/down on an individual response;
• model- or plan-specific feedback prompts, where available;
• /feedback, which uploads context/diagnostics and returns a Feedback ID;
• Start Performance Trace, which captures diagnostics but is not a case-management system;
• Help Center support chat, which begins with an automated assistant and may or may not become a trackable human-support case;
• public OpenAI Community / Developer Forum posts;
• Discord bug-report discussions referenced by community members;
• informal Reddit visibility;
• public GitHub issues, primarily used by developers and unsuitable for private account or conversation evidence.

These mechanisms do not form one coherent reporting workflow. They produce different identifiers, have different privacy models, and generally do not provide one place where a user can search for duplicates, create a report, attach diagnostics, follow status, answer engineering questions, or see whether the issue was fixed.

A company building agentic software should not require users to manually coordinate several disconnected reporting systems—or rely on an external developer platform—to report problems with OpenAI's own products.

Existing-report search

I searched this tracker before filing. I did not find an exact issue requesting a general OpenAI-native, account-linked issue tracker plus a ChatGPT reporting app/plugin.

Related but narrower reports include:

• #32225 — identifies a Feedback Intake Failure and requests a private engineering-feedback channel, selective diagnostic attachment, a stable case identifier, and confirmation that a report reached the correct team.
• #36471 — documents the practical dead end among /feedback, Help Center chat, email, GitHub, Reddit, and AI phone support, including uncertainty about whether a human case exists.
• #21300 — demonstrates the current two-step workflow: /feedback produced an ID, but the user was then told to manually open a GitHub issue containing that ID.
• #37581 — documents inconsistent product/reporting taxonomy across ChatGPT Desktop, Work, Codex, GitHub templates, labels, documentation, and support.

There is also a closely related OpenAI Community feature request from May 2025 asking to submit bugs and feature requests directly to OpenAI developers from ChatGPT:

https://community.openai.com/t/feature-request-submit-bug-feature-requests-to-openai-developers-directly-from-chatgpt/1248806

This issue expands that concept into a concrete, trackable reporting platform rather than a one-way feedback submission.

Current channel fragmentation

1. Thumbs up/down is response feedback, not an issue object

Thumbs feedback is useful for model-quality signals, but the user generally does not receive:

• a stable issue URL;
• duplicate detection;
• triage status;
• an assignee/team;
• follow-up questions;
• a resolution state;
• release/fix notification.

It is therefore not a substitute for reporting a reproducible product bug.

2. /feedback uploads evidence but is not a user-visible tracker

/feedback can return an identifier such as:

no-active-thread-...

That identifier is valuable for correlating uploaded diagnostics, but users cannot normally:

• open the report and review exactly what was submitted;
• see its current status;
• add a clarification or new reproduction;
• link a second affected conversation;
• determine whether it was deduplicated;
• know which team received it;
• subscribe to updates;
• see the fix version;
• close or reopen it.

The current desktop flow can explicitly tell the user to take that Feedback ID and manually create or update a GitHub issue. That proves the in-product feedback object is not itself functioning as a complete issue.

3. Performance traces are diagnostics, not cases

Start Performance Trace is useful for collecting timing and runtime evidence. But the trace should attach to a structured report; it should not exist as another isolated reporting concept that the user must manually correlate later.

4. Help Center support is a different and opaque workflow

OpenAI's official support guidance directs users to the chat bubble on help.openai.com, where they first interact with a virtual assistant and may later reach a human:

https://help.openai.com/en/articles/6614161-how-can-i-contact-support

That route is appropriate for account, billing, entitlement, and individual support, but it is not a transparent public engineering issue tracker. Users may not know whether a product defect was routed to engineering, merged with a known issue, or merely answered as troubleshooting.

OpenAI's AI phone support documentation is even more explicit that the automated phone agent cannot submit a report, initiate an escalation, connect a live agent, or guarantee follow-up:

https://help.openai.com/en/articles/11391933-ai-phone-support

5. Community forums and Discord are discussion channels, not authoritative case systems

Community posts can gather corroboration and workarounds, but their relationship to formal engineering intake is unclear. Historical OpenAI Community discussions have directed ChatGPT bug reporters toward Discord while simultaneously noting uncertainty about whether OpenAI employees respond there:

https://community.openai.com/t/is-there-a-category-that-we-can-report-bugs/256214

The forum itself contains repeated examples of users asking where bugs should be reported, reporting that support produced only automated replies, or posting publicly because no clear direct channel existed.

6. Reddit is useful for visibility, but is not an official OpenAI issue tracker

Reddit may help users discover that others have the same problem, but it has no authoritative linkage to an OpenAI engineering case, no official status lifecycle, and no controlled diagnostic channel.

7. GitHub provides the best issue concept, but it is not sufficient for all OpenAI users

GitHub has the right core primitives:

• searchable issues;
• duplicate handling;
• labels;
• comments;
• status;
• links;
• notifications;
• public history.

But requiring ordinary ChatGPT users to create GitHub accounts and understand repositories, templates, labels, and public redaction is not an appropriate universal reporting design.

GitHub is also unsuitable for:

• private account/entitlement evidence;
• unredacted conversation context;
• confidential Work outputs;
• proprietary files;
• private screenshots/logs;
• billing and subscription data.

The GitHub connector proves that ChatGPT can already search, create, update, comment on, and close structured issues through conversation. OpenAI should expose equivalent functionality for OpenAI's own issue system.

Proposed solution: OpenAI Feedback Hub + official ChatGPT reporting app

Create a first-party, account-linked OpenAI Feedback Hub with an official ChatGPT app/plugin—conceptually similar to the GitHub connector—supporting bugs, regressions, feature requests, documentation issues, model-quality reports, safety false positives, and support-linked product incidents.

Possible entry points:

• @OpenAI Feedback
• /report
• /issue
• Report a product issue in the message menu
• Create issue from this conversation
• a dedicated Feedback/Issues area in ChatGPT settings or the sidebar

The assistant should be able to use explicit tools conceptually equivalent to:

search_reports
create_report
fetch_report
add_comment
attach_feedback_id
attach_performance_trace
attach_conversation
subscribe_to_report
close_report
reopen_report

The exact API is less important than the user-visible guarantees below.

Required report model

Each report should have a stable OpenAI issue/case ID and canonical URL, for example:

OAI-CHAT-12345
https://feedback.openai.com/issues/OAI-CHAT-12345

A report should capture independent fields such as:

• product: ChatGPT, Work, Codex, API, Apps, Desktop, mobile, etc.;
• surface/mode;
• platform and app version;
• account plan/workspace type;
• issue type: bug, regression, feature request, documentation, safety false positive, performance, support/entitlement;
• severity and impact;
• steps to reproduce;
• expected behavior;
• actual behavior;
• timestamps/time zone;
• affected conversation/thread/request IDs;
• existing /feedback IDs;
• performance-trace IDs;
• screenshots/files/logs selected by the user;
• privacy scope: public, private to OpenAI, or public summary with private evidence.

Public issue plus private evidence

The system should support two linked layers:

1. Public/aggregated issue for searchable symptoms, workarounds, duplicates, votes, status, and release notes.
2. Private account-linked incident/evidence record for diagnostics, conversations, logs, account data, and confidential attachments.

This would allow many affected users to subscribe to one public issue while each user privately attaches their own Feedback ID and reproduction data.

Duplicate detection and corroboration

Before creating a report, the official reporting app should search existing reports and show likely matches.

The user should be able to:

• subscribe or add Me too / affected;
• attach a private reproduction to an existing issue;
• create a distinct report when the symptom materially differs;
• see why a report was marked duplicate and which canonical issue controls;
• retain their private evidence even after public deduplication.

This would reduce duplicate reports while preserving useful diagnostic diversity.

Trackable lifecycle

Users should see a clear status such as:

Draft
Submitted
Received
Triaged
Needs information
Confirmed
Duplicate of OAI-...
Planned
Fix in testing
Fixed in version ...
Not planned
Unable to reproduce
Closed
Reopened

The report should show:

• last meaningful update;
• responsible product area, when publishable;
• requested user action;
• related known issue/status incident;
• workaround;
• release containing the fix;
• whether private evidence was reviewed.

Users should receive in-product/email notifications for material changes.

Consent and diagnostic privacy

Before submission, the user must be able to preview and selectively approve every evidence category:

• current conversation;
• selected messages only;
• diagnostics/logs;
• performance trace;
• screenshots;
• files;
• account and device metadata;
• plugin/connector state.

The system should clearly state:

• what is included;
• who can access it;
• whether it may be used for training/product improvement;
• retention period;
• how to remove private evidence;
• what will appear publicly.

A user should never need to publish confidential evidence on GitHub merely to make a bug actionable.

Pro and paid-plan experience

Paid users—including Pro users relying on Pro models for consequential work—need a coherent reporting experience, not additional overlapping feedback buttons whose routing and status are unclear.

The reporting hub should make plan-aware routing transparent without promising that every report receives an individual engineering response. It should state:

• whether the report is product feedback or a support case;
• whether account-specific action is required;
• whether a human response is expected;
• applicable response expectations, if any;
• when the user should also contact support.

Relationship among existing feedback surfaces

Existing mechanisms should feed one system rather than compete:

• thumbs down → optionally create/link a model-quality report;
• /feedback → create or attach a diagnostic evidence package;
• Performance Trace → attach trace to a report;
• Help Center support → link a support case to a product issue;
• public Community/Discord posts → optionally link as corroboration, but not serve as the authoritative record;
• GitHub → remain appropriate for open-source Codex code issues while linking to the corresponding OpenAI product issue where relevant.

Critical trust requirement

ChatGPT must never tell a user that it reported an issue to OpenAI unless a real report object was created and the assistant returns its stable ID/status.

The user should receive an explicit receipt such as:

Created OpenAI issue OAI-CHAT-12345
Visibility: public summary + private diagnostics
Attached: Feedback ID ..., Performance Trace ...
Status: Received

This prevents the common confusion where users ask ChatGPT to “report this,” and the model describes a report without actually sending anything.

Acceptance criteria

• A user can search OpenAI product reports directly from ChatGPT.
• A user can create a structured report without leaving the conversation.
• The assistant shows the complete draft, visibility, and proposed attachments before submission.
• Submission returns a stable OpenAI issue/case ID and URL.
• Existing /feedback and Performance Trace IDs can be attached.
• Public and private evidence can be separated.
• Duplicate detection occurs before creation.
• Affected users can subscribe/add corroborating evidence.
• Users can view status, comments, requests for information, workarounds, and fix versions.
• Material changes generate notifications.
• Support cases and engineering issues can be linked without being confused as the same thing.
• ChatGPT cannot falsely claim that a report was sent when no report object exists.
• The system works for ordinary non-developer ChatGPT users and does not require GitHub, Discord, Reddit, or public disclosure.

Expected outcome

OpenAI users should have one authoritative answer to:

Where do I report this, what exactly was submitted, who received it, what is its status, and how will I know when it changes?

The current collection of thumbs feedback, /feedback, performance traces, support chat, Community, Discord, Reddit, and GitHub does not provide that answer. An OpenAI-native issue tracker and official reporting app/plugin would make feedback more actionable for engineering, safer for users, easier to deduplicate, and substantially more trustworthy.