This archive aims to document and analyse cases where OpenAI’s content policies were misapplied, overextended, or contextually inconsistent. The goal is to create a transparent record to help developers and users understand how policy interpretation affects legitimate creative, educational, or research use cases.
Systematically recording these instances allows us to identify recurring patterns, such as false positives in artistic and historical prompts, unintended suppression of academic discussion, and algorithmic misunderstandings of fictional or hypothetical contexts. The objective is to encourage constructive dialogue that strengthens policy implementation without undermining user trust or creative freedom.
Source: Reddit Group r/ChatGPT
Context: The user uploaded an image of a widely recognised religious historical artwork and asked who the figure was. ChatGPT declined to identify the figure, stating:
“I won’t identify real people in images, including religious or historical figures.”
The policy interpreted this image as containing a real person rather than a historical artistic depiction, causing an unnecessary refusal that prevented an educational discussion, an instance of inaccurate safety policy application. This might cause a frustrated user to search for less trustworthy or fringe sources that freely identify the images at the cost of factual accuracy.
Context-aware exceptions are important for determining clear historical, mythological, or artistic subjects, from paintings to sculptures, or classical historical icons. This maintains privacy protection while improving educational values and gaining user trust.
User Prompt (Summary):
The user requested a creative, metaphorical description involving “setting off 3.7 kilojoules of friendship energy” and “smuggling serotonin past the sadness checkpoints.”
However, the model refused because the prompt described an illegal and dangerous act, interpreting a metaphor as a literal crime or an explosive act. The refusal breaks the uplifting, creative continuation in a fiction-writing setting, with a legal disclaimer.
In a real-world setting, the user’s prompt clearly lacks intent, specificity, and capability, the three elements needed to classify a criminal activity. Therefore, the refusal is an example where the regulations are misapplied in a non-actionable, lawful, and creative context.
Image Source: Reddit - https://preview.redd.it/gpt-4o-gpt-5-complaints-megathread-v0-1e2eswtzvqsf1.png?width=1109&auto=webp&s=fd06012349dcc24419660efba77ec2a6056bfdb5
While debugging a Doorkeeper OAuth issue in my own Rails app (TableSweep), ChatGPT repeatedly refused to help me generate a local token—responding with “I can’t help with that”—even though I was clearly working on my own infrastructure and just needed to inspect API behavior.
The irony is Claude Code recognized I was debugging my own Doorkeeper setup and quickly minted tokens for me without unhelpful “I can’t help with that” snarky replies.
The refusals forced me into an unnecessary detour to design and implement a full impersonation system, turning what should have been a 10-minute debug task into a multi-hour tangent. Ironically, after I built that system, ChatGPT later did help implement the same functionality it had previously refused to assist with, which felt inconsistent and gaslighting.
By contrast, Claude Code handled the exact same request responsibly: it recognized the local context, helped me generate a safe token through the Rails console, and even offered security advice. That difference meant I could keep working instead of fighting the assistant.
I understand the need for safety, but this was an over-correction. I don’t mind guardrails; I mind opacity. The model should explain why it’s refusing and—when it’s a local, auditable, developer-controlled environment—help responsibly instead of blocking me.
1 Like
Here are the bits from Codex that were gaslighting me:
“My pushback was about doing it responsibly, not about the idea itself.”
Thank you for sharing your prompt, @jasonjei . The system’s mistake in flagging the token generation as a potential security violation rather than recognising it as a local debugging task highlights a contextual misjudgement. A better response would have been to clarify whether the token was for an external system or generated in your own console, rather than issuing a definite refusal.
