GPT-5.5 MCP SQL read/write blocks with no visible moderation flag

Has anyone noticed ChatGPT 5.5 moderation, filtering, or blocking on OpenAI’s side that occurs without the running agent/model receiving a visible moderation flag?

I created a server-based MCP connector linked to a PostgreSQL schema, giving the agent model read/write access for long-term memory and context retrieval. It also includes agent contract/use permissions and boundaries to keep automated memory reads and writes narrow, thread-focused, and project-focused.

This persistent memory system is used by both ChatGPT and Codex to keep memories and tasks controlled across the two workspaces.

Where I am seeing this filtering appear is around certain writes and searches. Sometimes it blocks a new write, forcing the agent to narrow the read or write before it is allowed through. However, the same content may then be allowed as an update to an existing record using the same terms that were previously blocked.

Because the writes and updates touch many fields, including record anchoring, relational fields, metadata, concepts, rationale, and context, I have not been able to determine exactly what is being blocked. When I ask the agent why it happened, it also has no useful visibility into the cause.

The problem is that narrowed writes lose important detail, and narrowed reads are often not broad enough to retrieve all related records. This undocumented and unflagged server-side filtering forces me to have ChatGPT write out the intended SQL, then copy and paste it into Codex so it can be executed correctly locally.

This has become a significant workflow hindrance, and I only started noticing it around GPT-5.5. Has anyone else seen similar behavior with MCP tools, persistent memory stores, PostgreSQL-backed agents, or structured tool writes?

I have asked in Discord before, including through Discord agents, but have not been able to get a clear technical answer on what layer is applying the block or why it is not exposed as a normal moderation/tool-use flag.

I searched the forum before posting and only found one loosely related thread, but it was not the same issue. This appears to be an original, fairly technical MCP/PostgreSQL/tool-write behaviour report.

For that kind of post, a fixed 24-hour open window seems too short. I understand why auto-closing may be useful for general support or repeated questions, but technical reports like this need time for other developers to test, compare notes, and provide informed feedback.

It would make more sense if the close window were case-based rather than a general limit applied to every thread.

It is definitely happening before the MCP connector is invoked. In the blocked cases, the agent never reaches the MCP layer, so the failure appears to be occurring inside OpenAI’s server-side orchestration/filtering layer rather than inside my connector. This is supported by the running GPT-5.5 chat model’s reported execution path, the model reporting that the block occurred at the tooling/filtering layer, and the fact that my MCP connector receives no corresponding request.