Oh. I found quite a few similar reports, so I think this is probably a bug:
The closest public report I found is OpenAI’s openai-apps-sdk-examples issue #230, opened on September 3. Its strongest reproduction is almost the same shape as yours:
same standard ChatGPT conversation
↓
Developer MCP works repeatedly
↓
later message in the same conversation
↓
explicitly select the same MCP app again
↓
FORBIDDEN: This conversation does not support developer MCPs
That issue is still open as of September 10. I could not find a published root cause or confirmed fix yet.
There are also several related reports in the OpenAI Developer Community. One of the more useful reproductions narrowed the boundary further: the MCP could be called successfully, but after crossing into the next user turn the connector disappeared from the @ picker and ChatGPT’s available tool set. Importantly, no second request reached the MCP server at all. The same MCP service remained usable from another OpenAI client in the control test. See Custom MCP connector disappears after successful invocation in Chrome Web Chat and Desktop Chat — no second request reaches MCP server.
So I would not assume this is your customer’s MCP server becoming unavailable. At least some very similar reproductions appear to fail before dispatch reaches the MCP server.
I also would not call the internal cause known yet. “Conversation/session state”, “rehydration”, “tool registration”, “routing”, etc. are reasonable places to investigate, but I have not found enough public evidence to say which internal mechanism is actually responsible.
The cheapest useful check, if you have access to the server logs, would probably be:
- In the already-broken conversation, explicitly select or
@mention the MCP app again and make one simple read-only call.
- Check whether that exact attempt reaches the MCP server or tunnel at all.
- Immediately try the same app + same model + same read-only call in a fresh standard chat.
- Note whether the broken conversation still shows the app in the
@ picker.
That gives a surprisingly useful split:
Broken conversation
|
+-- MCP no longer visible/selectable
| |
| +--> investigate ChatGPT-side app/tool exposure
| or conversation capability state first
|
+-- MCP visible, but call gives FORBIDDEN
|
+-- no request reaches MCP server
| |
| +--> failure is probably upstream of
| the MCP implementation itself
|
+-- request reaches MCP server
|
+--> inspect OAuth, HTTP response,
protocol version, proxy/routing,
and MCP-side state
Fresh-chat control
|
+-- same call succeeds
| |
| +--> conversation-specific state becomes
| substantially more plausible
|
+-- same call also fails
|
+--> broaden back out to app/account/workspace,
permissions, authentication, or server state
One important control here: OpenAI’s current Developer Mode/MCP documentation describes app selection as applying to the individual message rather than automatically granting indefinite use throughout the conversation. So I would make explicit selection on the failing turn part of the reproduction before concluding that tool persistence itself failed.
Closest related reports and why I think they are relevant
1. OpenAI examples issue #230 — probably the closest match
openai/openai-apps-sdk-examples #230 describes a standard ChatGPT conversation that successfully executes a custom MCP many times and later transitions to:
FORBIDDEN: This conversation does not support developer MCPs
The reporter explicitly reselected the app before the failing invocation. Developer Mode had not intentionally been disabled, the app remained configured, and its permissions were still present.
That is useful because it distinguishes the failure from the simpler case where somebody selected an app once and expected it to stay selected forever.
The same report also mentions separate failures such as:
Resource not found: <tool>
and:
<tool> has been disabled
but I would keep those separate from the strongest FORBIDDEN reproduction unless evidence shows they share a cause.
A stale individual tool definition could plausibly explain some “resource not found” failures; it does not obviously explain why a conversation that was already successfully executing the MCP later becomes categorically ineligible for developer MCPs.
2. Connector disappears across the user/assistant turn boundary
The turn-boundary report tested a custom MCP backed by a Cloudflare Worker in both ChatGPT Web and Desktop Chat.
The initial call succeeded and returned HTTP 200.
The important transition was:
MCP visible/selectable
↓
successful tools/call
↓
server returns HTTP 200
↓
next user turn
↓
connector absent from @ picker
↓
no second MCP request reaches server
The author also used another OpenAI client as a control against the same MCP service, which is useful because it makes a simple MCP-server outage less likely for that particular reproduction.
I would still describe this as a closely related observation rather than assume it has the identical root cause as your FORBIDDEN transition.
3. Similar “tools disappear after initially working” reports
There is also another recent Developer Community report where:
MCP loads
↓
tools are visible/callable
↓
after time / additional turns
↓
tools disappear
↓
MCP server receives no failed request
The reporter tested browser/client changes, different network routes, one versus multiple MCPs, and observed that creating a newly named MCP app could temporarily restore visibility.
That thread contains speculation about regional routing, VPNs, caches, tool counts, rate limits, etc. I would not treat those suggestions as established causes. The useful evidence is the observable boundary: when the tools disappear, the server sees no invocation.
A few failure modes I would keep separate
There are several mechanisms that can look similar from the user’s side, so I would avoid treating every FORBIDDEN or missing-tool case as one bug.
Message-level app selection
As mentioned above, OpenAI’s current Developer Mode documentation makes message-level app selection an important control.
If a later message simply does not have the MCP app selected, that alone is not sufficient evidence of a persistence bug.
That is why an explicit reselection on the failing turn is useful.
Conversation / Project / workspace capability
The same This conversation does not support developer MCPs wording has appeared in a separate report where the same custom MCP worked in one Project but failed in another.
That suggests the error text is probably not a unique fingerprint for this long-running-conversation failure.
An OpenAI_Support account replying in that Community thread also suggested comparing against a new blank Project/chat with the same model and only the MCP enabled. I would treat that as useful forum guidance, rather than as a published specification of ChatGPT’s internals.
For a reproducible report, I would preserve whether the affected context was:
standard Chat
Project
Work
another mode/client
plus the account/workspace type.
OpenAI’s Developer Mode/MCP documentation still describes this functionality as beta and makes availability/permissions dependent on plan and workspace configuration, so that context is worth recording even if it does not turn out to be causal.
Tool/action snapshot changes
The same OpenAI documentation also describes refreshing an MCP app after server-side action changes rather than assuming every server schema change is immediately reflected in ChatGPT.
So if the MCP server’s tool schema changed between the last successful call and the first failure, I would record that too.
Again, though, this seems more naturally able to explain a particular stale or missing tool than a conversation changing from repeated successful MCP execution to a blanket:
This conversation does not support developer MCPs
OAuth / authorization expiry
A long-running workflow can expose token-refresh problems that never appear during a short test.
But server-side logs make this branch much easier to distinguish:
failed attempt reaches server
→ authentication/protocol/server investigation makes sense
failed attempt never reaches server
→ authentication handling inside the MCP endpoint is much less
likely to be the immediate failure boundary
MCP protocol “session” vs ChatGPT conversation state
I would be a little careful with the word session here.
It can mean several different things:
ChatGPT conversation/runtime state
OAuth/authentication state
MCP protocol-level session
application-specific state inside the MCP server
Those are not interchangeable.
This matters especially because the MCP protocol itself has changed. The MCP 2026-07-28 specification release moved the modern protocol core to a stateless design and retired the old initialize / initialized handshake and Mcp-Session-Id.
Older MCP revisions and implementations may still use the earlier sessionful transport behavior, so a legacy deployment can still have issues such as session expiration or worker affinity.
Therefore, before chasing an “MCP session expired” explanation, I would first record the actual MCP-Protocol-Version involved.
And if the failed ChatGPT turn never produces an HTTP/MCP request at all, server-side MCP session handling is downstream of the failure boundary anyway.
Why the long-running-conversation part is still interesting
I did find some useful precedent in other agent/MCP hosts, although I would not treat this as proof of ChatGPT’s internal cause.
One particularly relevant example is OpenAI Codex issue #34719, where a manual context compaction succeeds but the first model turn afterward is provisioned without tool_search, deferred app tools, or configured MCP tools that were available immediately before compaction.
In that report, the app/connector cache remained populated; the visible failure was that the resumed model turn received a reduced tool manifest.
That provides a concrete example of this general failure shape:
long-running state
↓
context/session reconstruction boundary
↓
effective tool inventory must be rebuilt
↓
rebuilt inventory differs from previous turn
That is an interesting mechanism to compare against your observation, but it is a Codex report, not evidence that ChatGPT uses the same path or has the same bug.
So I think this is a reasonable question:
Does the first failure correlate with some conversation/context reconstruction boundary?
But I would avoid saying:
ChatGPT context compaction causes this.
unless someone can correlate the ChatGPT failure with such an event or OpenAI confirms it.
A few low-cost things worth recording if they happened immediately before the first failure are:
model switch
client switch
page/app reload
sleep/resume
very large tool result
very long conversation
conversation summarization/compaction-like transition
MCP refresh/schema change
These are comparison variables, not assumptions about the cause.
If you want a compact reproduction/support packet
If this is reproducible enough to send to OpenAI, I think a small packet like this would be more useful than a large diagnostic dump:
Environment
- ChatGPT client:
- model:
- standard Chat / Project / Work / other:
- account/workspace type:
- Developer Mode enabled: yes/no
- MCP app explicitly selected on failed turn: yes/no
- approximate number of exposed tools:
- MCP protocol version, if known:
Timeline
- last successful MCP invocation:
- first failed invocation:
- exact error text:
Observed state at first failure
- app still visible in @ picker: yes/no
- tool still appears model-visible, if observable: yes/no/unknown
- request reached MCP server/tunnel: yes/no/unknown
- server HTTP/MCP response if request arrived:
Control
- fresh standard chat:
- same model:
- same MCP app:
- same simple read-only tool:
- result:
Changes between last success and first failure
- model/client change:
- app refresh:
- MCP schema change:
- authentication change:
- other known change:
I would keep conversation IDs, credentials, tokens, private endpoint details, and customer-sensitive information out of the public forum post.
Conversation IDs and exact timestamps may be useful to OpenAI for tracing, but they are better supplied privately to Support or maintainers.
If the MCP exposes many tools, an optional secondary control would be a tiny version exposing only one to three fixed read-only tools against the same backend.
That would distinguish:
full tool catalog fails
minimal catalog survives
from:
both fail at the same conversation boundary
I would only do this if the basic server-log/fresh-chat comparison does not already narrow the problem. It is not the first thing I would ask someone to build.
Scheduled Tasks
I would currently keep the Scheduled Tasks observation as a separate but potentially related branch.
OpenAI’s Scheduled Tasks documentation says scheduled tasks can use supported connected apps when those apps are available for the relevant account/workspace, and that app permissions and workspace controls still apply.
What I have not found is public documentation specifying exactly how an arbitrary custom Developer MCP’s execution/tool state is reconstructed across scheduled reruns, or a strong independent reproduction showing that the Scheduled Tasks failure and the normal-chat FORBIDDEN failure share an internal cause.
So I think your observation is worth preserving:
initial scheduled run succeeds
later run loses MCP access
but I would not merge it into the normal-chat diagnosis yet.
For a scheduled reproduction, the analogous high-value observation would again be:
Did the failed scheduled run produce any request at the MCP endpoint?
If not, that would be a particularly useful datapoint because it would place the failure before the MCP backend in that execution context too.
One older issue that looks similar but should probably not be conflated
There was an older cluster of ChatGPT MCP reports where tool invocation failed with:
Resource not found
and the expected tools/call request never reached the MCP server.
For example, this Developer Community report recorded working initialize, tools/list, Inspector, and direct calls while ChatGPT’s tool invocation failed before reaching the backend.
That is useful precedent for distinguishing:
MCP server is unhealthy
from:
ChatGPT failed somewhere before dispatch to an otherwise healthy MCP
However, I would not identify that older Resource not found problem with the current September FORBIDDEN reports.
The visible errors differ, the conditions differ, and later discussion in that older thread reported a deployed fix for the issue being tracked there.
So I would use it only as historical evidence that “request never reached the MCP server” is a meaningful diagnostic boundary, not as evidence that the same regression returned.
For the moment, my working interpretation would be:
There are enough independent, recent reports that I would treat this as a plausible ChatGPT-side MCP lifecycle/capability bug rather than assuming the customer’s MCP server is at fault. At least some close reproductions fail before any follow-up request reaches the server. But the public evidence does not yet identify whether the underlying cause is conversation capability state, tool exposure/provisioning, routing, entitlement state, context reconstruction, or something else.
The most informative next datapoint is therefore probably not another reconnect attempt. It is simply:
On the first failed turn, after explicitly selecting the MCP app,
did any request reach the MCP server?
And does the identical call immediately work in a fresh chat?
If the answer is no request + fresh chat works, that would make your “conversation/session-specific” observation considerably stronger.
The fresh-chat workaround also recurs across the reports above, so for an important stateful workflow I would currently avoid treating a single long ChatGPT conversation as the only durable holder of state. Anything expensive to reconstruct — repository commit/hash, external object IDs, pending mutations, checkpoint/result identifiers, etc. — is safer to keep recoverable outside the conversation so that moving to a fresh chat is inconvenient rather than destructive.
I would also report this to OpenAI with the last-success/first-failure timestamps and the server-side “request received / not received” observation. The open openai-apps-sdk-examples issue #230 is probably the closest public report to cross-reference.