Write actions blocked on custom MCP server – Business plan workspace, Developer Mode unavailable at workspace level

ChatGPT Apps SDK
,
1

We’ve built a remote MCP server (Streamable HTTP) with both read and write tools and are trying to integrate it into a ChatGPT Business workspace. The server is fully functional — it works correctly as an MCP client in Claude, Copilot, and passes all tool calls when tested via MCP Inspector and direct API calls.

We followed the documented setup flow:

- Created and published the custom app from Workspace Settings → Apps → Drafts (Owner role)

- The app is available to all workspace members

- Connection is established successfully

- Read tools are discovered and called without issues

The problem is with writing tools, and we’ve narrowed it down to two separate but related issues.

-–

ISSUE 1: Write tool calls are blocked before reaching our server

When ChatGPT attempts to invoke any write tool, it never reaches our MCP server. No request hits our logs or API. ChatGPT returns these exact messages:

“This tool call was blocked by OpenAI’s safety checks. Please double check what you are sending.”

“No response returned from the write tool.”

We confirmed this is not specific to our custom server — the same behavior occurs with native apps like Google Drive (write actions blocked at the workspace level).

-–

ISSUE 2: Developer Mode is locked at workspace level (shows as Enterprise-only)

According to the documentation, write actions require Developer Mode enabled. We enabled it at the user level (Settings → Apps → Advanced Settings → Developer Mode) — that toggle works fine.

However, in Workspace Settings → Permissions & roles → Connected data, the section shows an “Enterprise” badge and the “Developer mode / Create custom MCP connectors” option has no toggle, it cannot be enabled at the workspace level for Business plans.

This directly contradicts the official Apps capabilities table, which lists both Write actions and Custom (MCP) as available for Business plans.

-–

Environment:

- Plan: ChatGPT Business

- Workspace role: Owner

- MCP transport: Streamable HTTP

- Developer Mode: enabled at user level only

- App published to workspace: yes

- Read tools: working

- Write tools: blocked, no server logs

- Same issue on native apps (e.g. Google Drive write actions)

-–

Questions:

1. Is workspace-level write action support for custom MCP apps intentionally restricted to Enterprise in the current beta, despite the documentation stating otherwise for Business?

2. Is there a workaround to enable write tools on a Business workspace without Enterprise-level Developer Mode?

3. Are the safety checks that block write tool calls configurable at the workspace level (e.g. via Action Control in Workspace Settings → Apps)?

4. Is there any MCP server-side configuration (beyond readOnlyHint annotations) required for write tools to be approved by ChatGPT’s safety checks on a Business workspace?

References:

-https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt

-https://help.openai.com/en/articles/11487775-apps-in-chatgpt

-https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business

3

No, write actions are available to everyone.

Developer mode is not an enterprise level feature, disabling it is. Could you show me what you’re trying to do in a screenshot?

I’m less certain about this, so I won’t say for certain what’s available at what tier here, but the workspace level thing you’re describing can mostly just be done per-app at this point.

No, if you publish an MCP to your workspace and you configure to allow writes, you should (probably) be good.

4

Thanks for the responses so far. I wanted to share additional findings that narrow this down considerably.

We have two versions of the same MCP server, with identical tool definitions:

  • Production server: https://mcp.your-domain.com/internal/mcp → write actions are BLOCKED
  • QA/testing server: https://mcp.your-domain-qa.net/platform02-core/mcp → write actions work SUCCESSFULLY

The only difference between them is the domain (.com vs .net). This strongly suggests the safety layer is evaluating the server’s domain as part of its decision to block write actions.

We tested two types of write actions to confirm this:

  1. Creating a new email from scratch
    • Production: blocked, no request for writing tools reached our server
    • QA: succeeded, edit link returned correctly
  2. Copying an existing email (simplest possible write action — no content, no parameters, just a copy)
    • Production: blocked
    • QA: succeeded, edit link returned correctly

The simple copy test is particularly relevant because it removes any possible variable related to content, URLs, or parameters. The only remaining variable is the server domain.

What we already tried:

  • Marked the tools as non-destructive in the tool definition (destructiveHint: false)
  • Simplified the tool call to its bare minimum (only library name and email name, no optional parameters)
  • Tried a plain copy with no extra parameters whatsoever
  • Verified server logs: no incoming request is registered when the call is blocked, confirming it never reaches our server

So my main question is: does anyone know why write actions are blocked specifically on the .com server while the equivalent .net one works fine? Any explanation would be super helpful.

Thanks again for your help.

5

I am sure you checked but who knows. What about the tls certificate? Is it valid?

6

I’m having the same issue with a custom MCP server on a personal Plus plan.

I’m running an instance of the iris-networks/terminal_mcp MCP server (not allowed to paste the GitHub link) and connecting it to a custom OpenAI app over a secure tunnel. When I use it in ChatGPT, OpenAI will frequently block tool calls and return this response to ChatGPT:

“This tool call was blocked by OpenAI’s safety checks. Please double check what you are sending.”

There isn’t much consistency over what tool calls OpenAI will block and which it won’t. Often ChatGPT will be able to try again and succeed, other times, nearly all or absolutely all tool calls to the MCP will be blocked by OpenAI.

Some clarity from OpenAI on why this is happening and what the expected patterns are to avoid this would be appreciated.

7

Thanks for the guidance on this. Sharing what worked for us in case it helps others hitting the same block.
Following the support team’s recommendations when we open a ticket thought support@openai.com, we made these changes:

  1. We rewrote the descriptions of our write tools (and the overall description of our MCP connection) to explicitly state that these tools are non-destructive: in our case, they only create or modify draft content, never send, publish, or delete anything, and never contact external recipients.
  2. We re-published our app after these description changes, since Business workspaces can’t update the published app’s tool descriptions in place.

This got the write tools working, at least partially. A few notes on stability, since we’re assuming this is expected given it’s still in beta:

  • The connector often reports as disconnected or says it can’t see the tools, even when it’s actually still connected. Simply asking it to “double check” or “look again” resolves it, without any real reconnection happening on our end.
  • Sometimes it says a tool call isn’t possible, but the same request works fine later in the same conversation.
8

Hello!

We are seeing the “This tool call was blocked by OpenAI’s safety checks.” a lot more recently, even on read_only tools.

What we have found:

  • This is coming either from the tool metadata or the tool call payload. We do give instructions in the tool description (with some emphasis on certain things to make sure the model uses the tool the best way possible), that could maybe be the root cause.
  • It is indeed very erratic. Sometimes the exact same tool call gets blocked, then chatGPT retries and it goes through.
  • Depending on the tool we see between 2% up to 30% ish tool call being blocked for the last few days.
  • Tools are read_only, everything else is false (destructive, openWorld).

Would be great indeed to get some guidance from OpenAi on that front.

9

I get the same issue, which started 2 days go. I’ve tried extensive testing in the past 2 days, tried with the browser and the desktop. It is not an issue with platform - I’ve tried with a .Net api and a node.js api. Tools that do not require parameters execute successfully. But Tools that accept one or more parameters are inconsistently blocked by ChatGPT. Once a block occurs in a window, that window is effectively poisoned. The request doesn’t even hit the mcp endpoint server. It’s clearly the Chatgpt client blocking the send request.

10

Let’s centralize discussion of the safety checks over here: ChatGPT App MCP tool calls blocked by OpenAI safety checks before reaching MCP server - #16 by casey-chow

I suspect this is something new.