I am in the same situation. I have attached Desktop Commander as a custom MCP to my conversation, but now the conversation is gated to only developer only MCPs for that chat conversation. I cannot use connected apps within that conversation once a developer MCP is attached to the conversation. Just so you are aware: I am on a Pro 20x account, and this is still gated. This is absolutely unacceptable.
Not to mention I was hit with a “Context Too Long” message in a long-term, very complex project build that I thought CGPT could handle, but there was no visibility into context usage. Thankfully I had built-in governance protocols and full history backups so I could spin up another session without losing any detail, but this is absolutely unacceptable… esp if you’re looking to make me pay $200 a month for this service.
This is the bug report directly from my ChatGPT session that hit this MCP connector issue:
Yes — here is a regenerated, cleaner version of the bug report, updated to reflect what we later discovered: DesktopCommander, Coda, and Google Calendar could be surfaced in the same thread, but Google Calendar read execution failed with FORBIDDEN: This conversation is restricted to developer MCPs.
OpenAI’s current Apps documentation says apps bring external tools/data into ChatGPT, may search/reference information or take actions, can be invoked with @ mentions or + → More, and that apps are available with all models except Pro models. (OpenAI Help Center) The original report language also appears in the prior transcript package you asked me to generate for tdc0.
Bug Report: Developer MCP Runtime Blocks or Degrades Connected App Access in ChatGPT Project Thread
Title
Developer MCP / DesktopCommander runtime appears to block or degrade standard connected app execution in ChatGPT project thread
Summary
In a long-running ChatGPT project thread, enabling or using a developer MCP-style tool such as DesktopCommander appears to create inconsistent access to standard connected apps such as Coda and Google Calendar.
The issue is not merely that connected apps are unavailable. In testing, DesktopCommander, Coda, and Google Calendar could all be surfaced in the same thread after explicit user invocation. However, Google Calendar tool calls then failed at execution time with:
FORBIDDEN: This conversation is restricted to developer MCPs
This suggests a distinction between:
-
app/tool namespace visibility,
-
app/tool invocation through the UI,
-
actual runtime permission to execute connected app calls.
That distinction is not clear to the user and makes project-level agent workflows unreliable.
Environment
Expected Behavior
A ChatGPT project thread should support reliable use of multiple connected apps/tools when they are installed, enabled, and explicitly invoked by the user.
Expected behavior includes:
-
A user can use a developer MCP tool such as DesktopCommander and standard connected apps such as Coda and Google Calendar in the same thread, if all are enabled and authorized.
-
If a connected app is visible to the assistant, harmless read-only calls should either work or produce a clear user-facing explanation of what permission or runtime condition is blocking execution.
-
If developer MCP mode restricts the conversation to developer MCP tools only, the UI should clearly warn the user before or during tool selection.
-
The desktop and mobile clients should expose comparable tool/app invocation behavior.
-
Switching model contexts should clearly communicate whether app/tool access will persist, be disabled, or require re-invocation.
Actual Behavior Observed
The behavior was inconsistent and difficult to reason about.
Initial State
DesktopCommander was available and callable.
Coda and Google Calendar were not initially visible in the active tool namespace, even though they were expected to be connected at the project/account level.
Phone-Side Invocation
When the user sent short messages from the phone naming the tools directly:
-
DesktopCommander
-
Coda
-
Google Calendar
the assistant was able to discover all three namespaces:
-
DesktopCommander surfaced with file/process tools.
-
Coda surfaced with document/page/table/search tools.
-
Google Calendar surfaced with search/read/create/update/delete style tools.
This suggested that the tools could coexist in the same thread at the namespace/discovery level.
Execution Failure
After Google Calendar surfaced, a read-only Calendar profile or event-search call failed with:
FORBIDDEN: This conversation is restricted to developer MCPs
This happened despite Google Calendar being discoverable as a tool namespace.
Desktop vs Phone Difference
The user reported that the desktop app made it difficult or impossible to select or surface multiple tools in one message, while phone-side tool-name messages appeared to expose the tools more successfully.
This suggests either:
-
a desktop UI limitation,
-
a tool invocation bug,
-
inconsistent client behavior,
-
or undocumented constraints around developer MCP sessions.
Pro Extended / Tool-Enabled Model Split
The project also hit a major workflow issue because Pro Extended is useful for reasoning, while Extra High / tool-enabled context is needed for tool use. Moving between these contexts creates operational friction for long-running project work.
Impact
This issue makes ChatGPT difficult to use as a single operational hub for project work requiring multiple tool domains.
The affected project requires:
-
local filesystem access for Markdown logs, handoffs, spreadsheets, and project files;
-
Coda access for task table validation and eventual controlled writes;
-
Google Calendar access for read-only planning context;
-
stable project governance across multiple AI agents.
Because tool access is inconsistent, the user must manually act as a bridge between tools, clients, and sessions. This defeats much of the purpose of connected apps and project-level agent workflows.
The result is increased coordination overhead, higher risk of state loss, and reduced confidence in ChatGPT as the primary project execution environment.
Why This Seems Like a Bug or Product Gap
OpenAI documentation presents apps as a unified framework for bringing external tools and data into ChatGPT. It also describes connected apps, action-capable apps, and custom MCP-backed apps as part of the same broader app system.
The observed behavior is confusing because a tool namespace can appear available while actual tool execution is blocked by a runtime restriction saying the conversation is limited to developer MCPs.
If this is expected behavior, it needs clearer UI messaging and documentation.
If it is not expected behavior, then developer MCP mode appears to interfere with connected app execution in a way that is not transparent to the user.
Reproduction Sketch
-
Start or continue a ChatGPT Project thread.
-
Use or enable a developer MCP-style tool such as DesktopCommander.
-
Attempt to access standard connected apps such as Coda and Google Calendar.
-
Observe that initially only DesktopCommander may be visible.
-
From mobile, send messages explicitly naming:
-
Coda
-
Google Calendar
-
DesktopCommander
-
Observe that Coda and Google Calendar namespaces may become visible.
-
Attempt a harmless read-only Google Calendar action, such as profile lookup or bounded event search.
-
Observe the execution failure:
FORBIDDEN: This conversation is restricted to developer MCPs
Requested Fixes
Please consider one or more of the following fixes:
-
Allow developer MCP tools and standard connected apps to operate together in the same ChatGPT project thread when the user has enabled them.
-
If developer MCP mode restricts app execution, clearly show that limitation in the UI before the user starts the session or invokes tools.
-
Distinguish visibly between:
-
app installed,
-
app visible to the model,
-
app selected in the current thread,
-
app callable in the current runtime,
-
app blocked by workspace/developer/runtime policy.
-
Allow users to add or remove apps/tools from a running project thread after creation.
-
Make desktop and mobile app invocation behavior consistent.
-
Provide an explicit error explanation when a connected app call is blocked by “developer MCPs,” including what the user can do to resolve it.
-
Clarify whether Pro-model contexts intentionally disable apps/tools and whether returning to a tool-enabled model should restore prior tool visibility.
Suggested User-Facing Error Message
Instead of only:
FORBIDDEN: This conversation is restricted to developer MCPs
show something like:
“This conversation is currently restricted to developer MCP tools. Google Calendar is connected and visible, but cannot be called in this runtime. To use Google Calendar, start or switch to a session/model context that supports standard connected apps, or disable the developer MCP restriction.”
Business / Workflow Importance
This matters for users who are trying to use ChatGPT Projects as long-running operational workspaces rather than one-off chats.
A project may reasonably need:
-
local files,
-
cloud documents,
-
task systems,
-
calendars,
-
spreadsheets,
-
and MCP tools
in one coordinated workflow.
If these cannot coexist reliably, users may need to move project execution to another agent host with more predictable tool orchestration.
Severity
High for long-running project workflows.
The issue blocks ChatGPT from serving as the primary operational cockpit for complex projects involving local files, Coda, and Google Calendar.
Current Workaround
The current workaround is to move primary build execution to another tool-hosting environment, while retaining ChatGPT as a reasoning/archive layer.
This is functional but undesirable, because it fragments project state and increases manual coordination work for the user.