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

[pdurlej]

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.”
2. In the same conversation, send a feedback message such as:
   • /feedback oracle i smoke to nie powinny być słowa problemy
3. 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.

[etraut-openai]

/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]

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]

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

[pdurlej]

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]

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.