This started with something very mundane: I found a rendering bug in the native Codex app on Linux.
Nothing catastrophic. Nothing security-related. Nothing requiring access to model internals.
The application simply reaches the bottom of its scrollable viewport while part of the rendered response remains inaccessible behind the composer.
I had a screenshot. I could describe the behaviour. I could provide the application version, operating system and reproduction steps.
I just wanted to log a bug. What surprised me was how difficult it was to determine what “log a bug” actually means within the OpenAI support ecosystem.
The problem isn’t the absence of reporting mechanisms, there are plenty of mechanisms.
There is the Help Centre chat bubble. There is in-product “Share feedback”. There are GitHub Issues for some products. There are separate pathways for account and billing matters, privacy, security and other categories.
The problem is that these are destinations, rather than a coherent support process.
In my Codex example, the Help Centre eventually directed me towards the openai/codex GitHub repository.
That initially seemed odd.
The repository prominently describes itself around Codex CLI, and its GitHub release stream is the CLI/tooling release stream. Meanwhile, the native Linux Codex application I am actually using is packaged as a .deb and subsequently maintained through the normal APT update mechanism.
There is, as it turns out, a dedicated Codex App Bug issue template in that repository. So GitHub Issues is apparently an accepted place for app bugs.
But the user has to discover and understand that relationship.
That is the problem.
Users should not have to understand OpenAI’s internal routing topology. From my perspective as the user, the relevant facts are straightforward, I am using an OpenAI product. The product has a reproducible defect.I would like to report it.
I should not have to determine:
- which engineering team owns the affected component;
- whether the problem belongs to ChatGPT, Codex App, Codex CLI or some shared underlying component;
- which GitHub repository happens to accept that category of defect;
- whether a Help Centre conversation counts as a support case;
- whether “Share feedback” is the appropriate mechanism;
- or which of several unrelated reporting surfaces OpenAI expects me to use.
That classification and routing should happen inside OpenAI, after intake.
At the moment, it feels as though part of the organisation’s internal routing table has effectively been exposed to the customer. “Share feedback” is not the same thing as “report a technical issue”.
Feedback is: I like this. I dislike this. This result wasn’t useful. I have an idea for improving the product.
A defect report is: Something in the released product is not functioning correctly. Please record the issue, triage it and give me a persistent reference to that record.
Those are different workflows.
The Codex app’s current “Share feedback” interface reinforces that distinction for me. It offers categories such as Bug, Bad result, Good result, Safety check, High RAM usage and Other. It also pre-selects options to include the current ChatGPT session logs and all browser tabs/browser logs.
For some defects those diagnostics, without a doubt would be extremely useful. For a simple reproducible viewport/layout problem, however, they are neither obviously relevant nor information I would want to provide by default.
A better principle would be data minimisation:
- Collect only what is required for initial triage.
- Ask for additional diagnostic information if the investigation establishes that it is necessary.
Diagnostics should be granular, clearly explained and opt-in.
GitHub Issues may be a perfectly good engineering destination, I don’t think GitHub itself is the problem.
For an open-source component, GitHub Issues can be an excellent engineering workflow. It provides deduplication, discussion, state, linking to commits and visibility to the community. The issue is making the customer determine that GitHub is the correct destination before the report has even been triaged.
There is also a legitimate privacy distinction between “I am comfortable publishing this defect and its evidence on a public engineering tracker” and “I need to tell OpenAI privately that one of its products is malfunctioning.”
Those shouldn’t be forced into the same workflow.
OpenAI could internally decide that a support case should become or link to a GitHub issue. That is an implementation detail that the customer shouldn’t need to manage.
Across OpenAI products, there should be one obvious action. Report a technical issue.
That should create a private, persistent case, something conceptually as simple as:
- Product: Codex AppVersion: automatically detectedPlatform: LinuxCategory: UI / Rendering
- What happened?
- What did you expect to happen?
- How can we reproduce it?
- Attachments: optional
- Diagnostic information: optional, granular and unselected by default
Then: Case OAI-123456 created
Currently - we talk to the chat bubble on the support page - I may or may not get an email two or three days later wondering if I still have a problem or if it’s resolved.
A customer logs a support request - OpenAI owns the routing. If it is a known issue, link it. If it belongs to Codex App engineering, send it there. If engineering wants it represented publicly on GitHub, ask whether the reporter is comfortable doing that or create an appropriately sanitised public issue. If it is actually caused by another OpenAI component, reroute it internally.
The customer-facing case remains the canonical record : Received → Triaged → Investigating → Known issue / Engineering → Resolved
This is very ordinary IT service-management behaviour, and that is precisely why I find its absence surprising.
The useful design question may be: what must be true?
For someone to successfully report a technical defect, what should they actually need to know?
I would argue:
- Which OpenAI product they were using.
- What happened.
- What they expected to happen.
- How to reproduce it, if known.
They should not need to know which OpenAI team owns the component, which repository corresponds to it, how that product is packaged internally, where its engineering backlog lives, or which reporting mechanism maps to which organisational boundary.
That knowledge belongs on OpenAI’s side of the support interface.
OpenAI’s product surface is becoming broader: ChatGPT, Codex, native applications, developer tooling, APIs, agents and increasingly sophisticated integrations.
As that surface expands, a model of “If it is this, report it here; if it is that, report it there; if it belongs to this product use GitHub; otherwise talk to the Help Centre…” will become progressively harder for users to navigate. Ironically, OpenAI is unusually well positioned to build an excellent intake layer.
An AI-assisted support system could classify the affected product, collect the minimum necessary evidence, identify likely duplicates, ask only genuinely missing questions and produce an engineering-quality escalation packet.
But the important outcome should still be very conventional: Your technical issue has been recorded. Here is its reference number.
The cleverness can happen behind that interface. The front door should be boring, obvious and dependable.
If this is indeed in place - then it needs far better communication around it.