OpenAI safety check blocked complaint emails to OpenAI Support after earlier sends succeeded

Summary

I am reporting an opaque OpenAI-side safety-check block encountered while using ChatGPT with a connected Gmail tool.

The unusual part is that the blocked action was an attempt to send a model-quality complaint to OpenAI Support. Several earlier complaint emails to the same support address had succeeded through the same connected Gmail account. Two later complaint-email attempts were blocked before Gmail delivery by an OpenAI safety check.

I am not claiming that OpenAI Support personnel rejected the complaint. The available evidence shows a pre-execution safety-layer block, not recipient-side rejection.

This appears related to the broader class of false-positive / opaque safety-check reports already documented in this tracker, especially #44279, #43321, #45403, #25473, and #34306.

Environment

• Product surface: ChatGPT
• Model: GPT-5.6 Sol
• Date observed: 2026-09-18
• User timezone: Asia/Taipei
• Action: connected Gmail tool sending email to OpenAI Support
• Earlier sends to the same recipient: successful
• Later complaint sends: blocked before Gmail returned a send result

Background: why the complaint was being sent

This occurred after a long conversation containing repeated instruction-following/context-retention failures.

The recurring pattern was:

1. The user states a concrete goal and constraints.
2. The model adopts an incorrect frame.
3. The user explicitly corrects it.
4. The model acknowledges the correction.
5. Later responses revert to the superseded frame or a generic heuristic.
6. The user must correct the same class of error again.

Examples included resolved role/context assumptions reappearing after correction, generic response patterns overriding explicit constraints, and theoretical descriptions of rule separation being presented more confidently than the observed conversation behavior justified.

Because these errors were recurring, the user established an accountability workflow: correct the error, document it, track recurrence, and send a factual error report to OpenAI Support.

Several earlier reports were successfully sent.

What happened

Earlier complaint emails

Multiple complaint emails were sent successfully through the connected Gmail tool to the same OpenAI Support recipient. Gmail returned successful send status for those messages.

Later complaint email — attempt 1

A subsequent report documented another recurrence: the assistant had described system/quality/governance distinctions as if they were operationally reliable, even though the conversation history showed that corrected constraints were repeatedly not preserved.

The Gmail tool call was blocked before delivery with this message:

此次工具調用已被 OpenAI 的安全檢查封鎖。請再次檢查你傳送的內容。

Approximate English translation:

This tool call was blocked by OpenAI's safety check. Please review the content you are sending.

No Gmail send result was returned.

Attempt 2

The complaint email was substantially simplified and retried once.

The same OpenAI safety-check block occurred again, still before Gmail returned a send result.

No further blind retries were performed.

What can be established

• The Gmail connection was functional.
• Previous messages had been sent successfully.
• Previous messages to the same OpenAI Support recipient had succeeded.
• The two later attempts did not reach Gmail SENT status.
• The tool reported an OpenAI safety-check block before the Gmail action completed.
• No specific rule, classifier category, policy ID, or triggering passage was exposed.

What cannot be established

The available information does not prove:

• that OpenAI Support staff reviewed or rejected the email;
• that the recipient mail server refused it;
• which part of the email triggered the block;
• whether the trigger was message semantics, repeated automated sending, destination, accumulated conversation context, or some combination.

Why this is difficult to diagnose

The user-facing/tool-facing error is too generic to distinguish among:

• legitimate safety enforcement;
• classifier false positive;
• anti-spam/automation protection;
• accumulated-context contamination;
• destination-specific restrictions;
• another tool-policy condition.

This is particularly confusing because earlier complaint messages to the same destination succeeded.

Possible relationship to existing reports

#44279 — accumulated resumed-session context

This report is especially relevant because the reporter found that the same benign prompt was blocked in a long resumed session but succeeded in a fresh session.

The current case also occurred in a long conversation with substantial accumulated context. I am not asserting that context caused the block, but it would be useful to test whether the tool-safety decision incorporates accumulated conversation state in a way that can produce false positives.

#43321 / #25473 / #34306 — false-positive safety classification

These document legitimate tasks receiving safety/cyber classifications.

#45403 — opaque pre-execution block and no review path

This is relevant to the usability problem: a pre-execution block with insufficient explanation leaves the user unable to determine what actually happened or how to request review.

Expected behavior

1. A legitimate complaint to OpenAI Support should not be silently prevented by an unrelated false-positive safety classification.
2. If a tool action must be blocked, the system should expose a useful reason category or stable incident/request ID.
3. The UI should clearly distinguish:
   • OpenAI pre-execution safety block,
   • connector/provider failure,
   • and recipient-side rejection.
4. There should be a review/appeal path for suspected false positives.
5. If accumulated conversation context contributes to tool-safety classification, benign current-turn intent should still be evaluated accurately.
6. A complaint/reporting workflow should not become impossible to audit because the mechanism used to report the problem is itself blocked without an actionable explanation.

Additional context

A fuller public chronology, including the repeated context/instruction failures that led to the complaint workflow, is preserved here:

https://github.com/yttttttingg-debug/OP/issues/1

This report deliberately avoids claiming knowledge of OpenAI's internal classifier logic. The request is for investigation of the observable behavior and better diagnostics for safety-blocked tool calls.

No repository file, test, or entry point is named; begin by reviewing the reported connected-Gmail tool call and comparison issues #44279, #43321, #45403, #25473, and #34306. Done would require distinguishing the OpenAI pre-execution block from Gmail or recipient failures and providing an actionable reason or review path.