›_ Codex Issues
Codex Issues / #20497

`/feedback` is recommended after a false-positive safety block, but sending `/feedback` is blocked too

Open 💬 5 comments Opened Apr 30, 2026 by pdurlej
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Summary

When a Codex/ChatGPT conversation is flagged with the “possible cybersecurity risk” banner, the UI tells the user to submit /feedback if the block seems incorrect. In practice, sending a /feedback ... message in that same conversation can be treated as normal chat content and blocked by the same classifier. This leaves the user with no working in-product path to report a false positive from the blocked conversation.

Environment

  • Product: Codex / ChatGPT conversation UI
  • Platform: macOS desktop browser/app context
  • Date observed: 2026-04-30
  • Screenshot evidence is available if maintainers need it; this was observed directly in the blocked conversation UI.

Steps To Reproduce

  1. In a Codex/ChatGPT conversation, trigger a false-positive block that shows the banner:
  • “This content was flagged for possible cybersecurity risk...”
  • The Polish UI says: “Jeśli to wydaje się nieodpowiednie, spróbuj inaczej sformułować prośbę lub wyślij /feedback.”
  1. In the same conversation, send a feedback message such as:
  • /feedback oracle i smoke to nie powinny być słowa problemy
  1. Observe that the feedback message is not accepted as a reporting action and the conversation remains blocked with the same warning state.

Expected Behavior

One of these should happen:

  • /feedback should open a dedicated feedback/report flow that bypasses the blocked chat response path, or
  • the warning banner should link to a separate report UI, or
  • the banner should not recommend /feedback unless that command is actually supported in the current blocked state.

Actual Behavior

The UI recommends /feedback, but sending /feedback ... in the blocked conversation appears to go through the same normal-message path and is blocked. The suggested recovery/reporting mechanism is therefore not usable.

Why This Matters

False positives are expected, but the current UX makes them hard to report:

  • the user is explicitly told to use /feedback,
  • the suggested command does not work in the blocked context,
  • there is no obvious alternative path from the same UI,
  • this creates a loop where the user cannot explain that the classification is incorrect.

Suggested Fix

Treat /feedback as a client-side command before normal model/safety routing, especially when the current conversation is already blocked. At minimum, the blocked banner should expose a direct feedback button/link that does not depend on sending another chat message.

Notes

The false positive in this case was about ordinary development/tooling terms in a discussion about a local Oracle CLI/Codex skill workflow. Terms like oracle and smoke were part of normal software testing language, not a request for harmful behavior.

View original on GitHub ↗

5 Comments

etraut-openai contributor · 3 months ago

/feedback uses a completely different upload mechanism and endpoint for this very reason.

If you're unable to upload to /feedback, that is usually explained by either a connectivity (network) issue, a firewall/VPN issue, or an IP-based CloudFlare block. Do you happen to recall what error message you received when attempting to use /feedback?

pdurlej · 3 months ago

Thanks for the quick reply. I don't think I ever reached the separate /feedback upload flow/endpoint.

What I observed was:

  1. The conversation was already in the blocked state with the “possible cybersecurity risk” banner.
  2. The Polish banner text explicitly suggested sending /feedback if the block seemed incorrect.
  3. I typed a message starting with /feedback ... directly into the same conversation composer.
  4. That did not open a separate feedback UI or show a distinct upload/network error. It appeared to be treated as a normal continuation message in the blocked conversation, and the same blocked-state UX remained.

So I don't have a separate /feedback upload error message to report. The bug may be one layer earlier: in this UI/context, the user-facing instruction makes it look like /feedback should be entered into the composer, but that path does not visibly route to the separate feedback mechanism.

If the intended behavior is that /feedback should open a client-side feedback flow before normal message routing, then it did not do that here. If the intended behavior is different, the blocked banner probably needs a button/link or clearer wording so users do not try to send /feedback as another chat message.

etraut-openai contributor · 3 months ago

Yes, when you type /feedback in the prompt within the app, you will see a separate dialog box appear that looks like this:

<img width="519" height="399" alt="Image" src="https://github.com/user-attachments/assets/eaf40c49-e6ed-4e90-893e-7db15900473a" />

pdurlej · 3 months ago

Thanks, that screenshot is helpful. That dialog did not appear in my case.

The context was:

  • The conversation was already showing the possible cybersecurity risk banner.
  • I was in the normal conversation composer below that banner.
  • I typed /feedback ... directly there, following the banner instruction.
  • I did not see the separate feedback dialog shown in your screenshot.
  • I also did not see a distinct upload/network error. The UI remained in the blocked conversation state.

So the bug may be narrower than my original wording: the /feedback command handler did not visibly intercept the composer input in this blocked conversation state/context.

Potentially relevant details:

  • UI language was Polish.
  • This was a ChatGPT/Codex conversation surface, not a terminal-only Codex CLI flow.
  • The chat was already flagged before I attempted /feedback.

If helpful, I can try to reproduce again and capture a short screen recording or inspect whether the feedback dialog is created and immediately dismissed/blocked.

pdurlej · 3 months ago

One possible root cause on my side: I use ControlD / DNS filtering. If the /feedback dialog depends on a separate endpoint, iframe, script, or domain, it may have been blocked before the dialog appeared.

I have disabled ControlD filtering for an hour and will try to reproduce again. If /feedback starts showing the dialog while filtering is disabled, then the root cause is probably local network/DNS filtering rather than the command handler itself.

Even in that case, there may still be a small UX issue: if the feedback flow fails to load because a network/DNS layer blocks one of its resources, the UI currently gives no visible fallback/error, so it looks like /feedback was ignored or treated as a normal message.