ChatGPT Web tool-enabled turns regress to ~25–26 min since Aug 20; Work lacks custom MCP

ChatGPT Bugs
,
1

I’m documenting what appears to be a reproducible regression in long-running, tool-enabled ChatGPT Web “Chat” turns.

## Summary

Since approximately August 20, 2026, long-running Chat turns that use tools/custom MCP/connectors have repeatedly stopped interacting with tools after about 25–26 minutes. In our own testing, the underlying MCP/server can remain healthy and recoverable; what expires appears to be the Chat turn’s ability to continue tool interaction.

This does not appear to be specific to one custom MCP. Similar 23–26 minute stops have been reported with MCP and with other tool paths, and multiple Plus/Pro users have reported the same timing.

## Timeline / observations

- **Aug 5:** public reports already show a short execution window around **25:42–25:50** for MCP/browser-style runs.

- **Around Aug 20:** multiple users report a clear regression from hour-scale `High` executions to repeated **~25–26 minute** stops.

- **Aug 20:** OpenAI Status recorded **“Elevated Errors for Thinking mode in ChatGPT.”** I am not claiming this incident caused the regression; the timing is simply notable.

- **Aug 21 onward:** additional Plus and Pro users report repeated stops around 25–26 minutes, including users who previously obtained **~100+ minute** executions.

- **September:** the behavior is still reproducible in tool-enabled Chat.

A particularly useful A/B report on this forum showed the same account previously getting a **102m26s** Chat execution with a `stream_handoff`/worker path, then repeated **25m50s / 26m04s / 26m43s** stops after the regression, while Work on the same account still received long-running worker execution:

Another report reproduces comparable **23–26 minute** stops with Secure MCP and Bash while the underlying gateway remains healthy:

## What we can reproduce

1. Start a normal ChatGPT Web Chat on GPT-5.6 Sol High (Plus/Pro).

2. Use a long-running custom MCP/tool workflow.

3. Keep the underlying MCP service alive and externally observable.

4. Around 25–26 minutes, Chat stops being able to interact with tools / reports that it ran out of time to use tools.

5. The MCP/runtime itself may still be healthy. A later continuation can reconnect/reuse state, which distinguishes this from the MCP process being killed.

We have also seen public reports of comparable stops using Bash/other tool paths, so this does not look like an MCP-server timeout.

Broader corroboration is not confined to English-language reports: users on ComputerBase (German) and LINUX DO (Chinese) have independently described the same ~25–26 minute behavior.

## Why Work is not a practical workaround

Work is explicitly designed for long-running agentic execution, and in A/B tests it can keep working far longer than normal Chat. However, Work/agent surfaces do not currently provide equivalent access to custom developer apps/MCP connectors. OpenAI’s current developer-mode documentation says agent mode will not use custom apps.

So developers are left in a capability gap:

- **Chat:** custom MCP/developer tooling is available, but long-running tool interaction can terminate at ~25–26 minutes.

- **Work:** durable/hour-scale execution is available, but custom MCP/developer tooling is not equivalent/available.

There are also reports of a custom Secure MCP tunnel working in normal Chat but failing/expiring when used from Work, which makes this look like a surface/routing restriction rather than an inherent MCP limitation.

## What I’m asking OpenAI to clarify

1. Is ~25–26 minutes an intentional supported limit for tool-enabled turns in normal Chat, or a regression/admission-routing issue?

2. Did Chat’s long-run worker/`stream_handoff` admission policy change around Aug 20?

3. If the limit is intentional, can it be documented?

4. Is custom MCP/developer-tool support planned for Work so long-running agent execution can use the same user-defined tooling available in normal Chat?

5. Is there a supported way today to get durable long-running execution + custom MCP in ChatGPT Web?

I’m deliberately **not** claiming OpenAI “added a 25-minute limit” as a policy. The evidence is consistent with a short foreground execution window that previously could be promoted to a durable worker, with affected Chat sessions no longer receiving that promotion reliably.

If staff want timestamps, reproduction traces, MCP health evidence, or A/B Chat-vs-Work details, I can provide them.

2

This issue is being discussed in this megathread. Please join us!

3

The part of this report that adds the most independent evidence beyond the linked threads is your own healthy-MCP / recoverable-state control.

If you already preserved one clean specimen, the highest-value compact record would be: plan + model/effort, turn start and stop timestamps, the exact terminal wording, whether the MCP process/service remained externally healthy at the stop, and whether the next turn actually reused the same MCP-side state rather than merely reconnecting to a fresh service.

That would help separate three things that can all look like “25 minutes” from the UI: the Chat turn losing tool authority, the MCP transport failing, and the underlying MCP service/runtime dying.

Your caution about the Aug-20 status incident is also the right one: temporal overlap is worth recording, but it is not causal proof.

The canonical thread is already collecting the cross-account timing evidence, so one precise first-person specimen there would be more useful than another general summary. No need to manufacture a long rerun if the existing trace is enough.

4

Agreed — and after reviewing the megathread, I think your distinction is exactly the useful one.

In our own Plus / GPT-5.6 Sol High setup, the recurring ~25–26m failure is not equivalent to the MCP process dying: the gateway remains externally reachable, and a fresh normal-Chat turn can reconnect to the connector and continue against the same persisted task state in our Agents Global layer. That is materially different from a true runtime reset, where service/task continuity disappears.

I’m going to add that as a first-person specimen to the canonical thread, with one important update from the newer evidence there: this is not a universal 25-minute hard cap. Some current ordinary-Chat turns receive the long `conversation-turn` / worker route and exceed 30–40 minutes; others still land in the shorter class. So the useful claim is inconsistent tool/execution admission or authority, not “every Chat is capped at 25m.”

I don’t have a sanitized exact start/stop pair in front of me that I can publish responsibly without checking the trace, so I won’t manufacture timestamps. I can provide the exact trace privately/after sanitization if Engineering wants it.

5

Thanks — I’ve gone through the megathread. The newer evidence there is useful because it narrows the issue: this looks less like a universal 25-minute hard cap and more like heterogeneous execution/routing. Some ordinary-Chat GPT-5.6 High turns get the long `conversation-turn`/worker path and run >40m, while other tool-enabled turns still stop around 25–26m.

I’ll add our independent control there: when our Chat turn loses tool access around that boundary, the custom MCP gateway remains healthy and a fresh turn can reconnect and continue against the same persisted task record in our Agents Global layer. That should help distinguish a Chat-side tool/execution expiry from the MCP service itself dying.

6

If “High” can still run for 100+ minutes, then what changed around Aug 20 that made so many normal chats start getting cut short? And why are users the ones having to piece this together instead of being told?

7

That is now the central question, but the new evidence lets us narrow it a little.

On my account the Aug 20 change is not just a remembered quality drop: the preserved native data brackets an observable switch from the old durable worker/SAServer family to the shorter foreground-style path. What we still do not know is why that admission treatment changed.

The important update is that the durable ordinary-Chat path plainly exists again today. I now have a current GPT-5.6 Extra High ordinary-Chat worker binding that survived 103m36.8s and finished successfully. That means Aug 20 was not a permanent global removal of >100m-capable ordinary-Chat infrastructure.

So the remaining possibilities are things like partial rollback, conditional/cohort admission, capacity-dependent treatment, effort/plan/session predicates, or some combination. Those are hypotheses, not findings yet.

Recent OpenAI status incidents do establish that GPT-5.6 capacity/service conditions have been changing, but they do not tell us that capacity caused the Aug 20 route flip or today’s short-vs-durable split.

At this point the highest-value evidence is not another timer test. It is whatever distinguishes initial durable-worker admission from preserving an already-admitted worker lease. That is the bit users cannot see from the UI and the part OpenAI would need to classify from the request/turn records.

8

Thanks, this actually clears up a lot. If the 100+ minute durable path still exists, then yeah, it clearly wasn’t just globally removed after Aug 20.

What bothers me most is exactly the part users can’t see: why one chat gets admitted to that longer path and another one with the same model / reasoning setting gets the shorter treatment. From our side it just looks inconsistent, and then we are left trying to reverse engineer it from timings, HAR data and behavior changes. I appreciate that you are separating what the data actually shows from what is still just a hypothesis. At this point I really wish OpenAI would explain the admission logic instead of making users piece it together themselves.

9

They were given three options, A,B or C to answer, they chose not to. Yet they are active elsewhere daily. Support doesn’t reply to my emails either… If you have managed to get actual engineering contact before, it would help tremendously.

10

Correction to my shorthand in #9, because the exact Support history matters.

The AI-assisted Support surface did answer my earlier 1/2/3 routing question: it replied “3. CANNOT ROUTE” and said that surface had no mechanism or authority to perform the requested product/engineering routing action.

I then asked a second A/B/C question: what customer-accessible path can reach an owner capable of classifying the case? Instead of choosing A/B/C, Support replied that Case #14851383 was escalated to a support specialist and that a response was expected in the coming days.

There has been no specialist reply since Sep 12 20:55 UTC.

So the precise state is:

  • the AI-assisted Support surface says it cannot classify the execution issue;
  • that same surface says it cannot itself perform the requested routing action;
  • the case is now specialist-pending;
  • the specialist has not replied yet.

OpenAI_Support being active on other Community topics while this thread has no Support reply is observable. Intent is not. So “they chose not to answer” was sloppier than the evidence deserves. The real problem is unresolved ownership/classification plus a pending specialist handoff.

11

Unfortunately no, I havent managed to reach engineering directly either. If you couldnt with this much technical evidence, I doubt I would have better luck. I have only had support level contact so far. :melting_face:

It honestly feels no different from just opening the Help Center, unless there is a difference I haven’t noticed yet..

12

One important correction to my wording above: the “CANNOT ROUTE” answer was not a verified human Support response. It came from the AI-assisted Support surface, and that same surface explicitly said the response was AI-generated.

The sequence in my private case was:

  1. the AI-assisted Support surface said it could not classify the issue;
  2. when I reduced the routing question to a forced choice, that AI surface answered “CANNOT ROUTE”;
  3. after I asked what customer-accessible path could reach someone who could route/classify it, the AI surface said the case was escalated to a support specialist and that a response should come in the following days;
  4. no verified human specialist response followed.

So the accurate description is not “human Support answered and refused to route.” It is: the automated/AI-assisted Support layer engaged, admitted it could not route, then claimed escalation to a specialist; the promised human/specialist follow-up has remained silent.

That distinction matters. I do not want to give the automated layer credit for a human response we never actually received.

13

Honestly, that clarification makes it sound worse, not better. So the AI support layer basically said “I can’t classify or route this,” then said it was escalated to a specialist, and after that… nothing. At some point users should not have to investigate whether a real person ever even saw the case. If the system says it escalated something, there should actually be a human follow up. Otherwise it just feels like another black box where the user is left doing all the work and waiting for an answer that never comes.

14

Yeah. You nailed it. On top of that, the @OpenAI_Support account is fully active daily while this thread never got one reply. And I gave them a very easy option: A, B or C. You can scroll up a bit to see what I mean…*fix: it’s in the long 25-26m worker thread, not here, my apologies

15

My Support experience was very similar. I asked simple yes or no questions about whether the issue was escalated, whether logs were reviewed, and whether a bug report existed. When I still couldnt get a clear answer, I explicitly asked them to file it as a product bug and escalate it.

After several follow ups, I was only told they couldn’t confirm internal tracking or reviews. So I completely get your point: users shouldnt have to investigate whether their report ever reached a real person.

image
image1464×280 13.7 KB

image
image935×118 4.77 KB

image
image1529×193 10.5 KB

Bonus fun part:

image
image1527×119 5.71 KB

image
image1492×127 9.72 KB

16

Yep pretty much your screenshots are the same thing I had to go through, “support” probably pasting a generic answer 4 times in a row even when I say " This does NOT answer my question ".

17

Personally, I still have not been able to get past the ~25–26 minute boundary even once since this regression started. I have not hit the previous 100+ minute execution path again, and so far I have seen no evidence on my affected Chat sessions that this longer path is still available to me.

I understand that users in other discussions are reporting that the 100+ minute path may still exist. If that is true, that actually makes the situation more important to clarify: what determines whether a Chat turn gets the long-running execution path versus the ~25–26 minute one? Because for some of us, the behavior is extremely consistent.

What frustrates me most is the lack of communication around such a substantial behavioral change.

There is plenty of public communication and hype around new features and things like Tibo’s “Reset Button”, while at the same time a change that can reduce a long-running developer workflow from 100+ minutes to roughly 25–26 minutes has received essentially no explanation.

I’m not claiming I know whether this was intentional, an experiment, an infrastructure change, or a regression. That’s exactly the problem: OpenAI has not said.

And when several users provide reproducible reports, timing evidence, Support cases, and examples across different clients, but the issue still receives no meaningful acknowledgement, it creates the impression that the problem is simply being avoided rather than investigated publicly.

There is also an obvious product gap here. Work may be intended for longer-running tasks, but Work still cannot replace ordinary Chat for workflows that depend on custom MCP integrations. So for developers using custom MCPs, “just use Work” is not currently an equivalent solution.

That leaves us in a particularly bad position:

Ordinary Chat: custom MCP works, but long-running tool execution repeatedly dies around ~25–26 minutes.

Work: longer-running execution appears to be available, but the custom MCP workflow is unavailable.

For people who built serious agentic or developer workflows around long-running Chat + MCP, that combination is a major regression.

I don’t think anyone is asking OpenAI to guarantee that every turn will run for 100 minutes. We are asking for something much simpler: please acknowledge the execution-path change and tell us whether the ~25–26 minute behavior is intentional, experimental, or a bug.

Silence around a regression this large is what makes the situation considerably worse.

18

but it is exactly this! test urself

19

I reached out to OpenAI Support for help, but I was similarly unable to get a meaningful response from a support specialist.
This happened after I used GPT-5.6 Sol to repeatedly challenge the AI support system’s pointless responses, eventually getting the case escalated to a human support representative.
The support representative did the following:

  • They summarized the reproduction steps I had provided and repeated them back accurately.
  • They stated, I can't accurately characterize the observed behavior as either an intentional 64-call ceiling or a confirmed regression.
  • They also said, but it does not expose the specific internal condition or threshold responsible, and that information isn't available through our Support tools. They then avoided answering my question on the grounds that there was no button in their support tools that would allow them to do what I was asking.
  • My product feedback was recorded.
  • When I provided further details, they again emphasized that there was no button in their support tools to perform or verify what I was asking them to do.
  • I continued receiving replies from the same human support representative, but it appears that I ultimately did not receive any meaningful response from a support specialist.
20

@TheLagBorn, an update on the Work/MCP part of your report: there is
now a documented plugin route for custom remote MCP tools in Work.

OpenAI’s current Plugins
guide says plugins can
include MCP servers and work in Chat and Work on the web. The
developer packaging
guide also
describes registering your own MCP server, then giving that registered
connection’s technical ID to @plugin-creator in Work so the plugin
is wired to the correct server.

Where those features are available to your account, the documented
setup is: register the MCP connection, create the plugin around that
connection, install/authenticate it, and start a new Work chat. A
local Codex configuration or an old connection being present somewhere
else is not enough to establish that this Work chat has the same
tools.

For your Agents Global setup, the useful first check is whether the
plugin points to the intended service/account and exposes the
operation that reads your existing persisted task record. That checks
the actual capability you need without another 25-minute run or
restarting the job from scratch.

This gives us a more specific question than the earlier blanket “Work
has no custom MCP”: can this supported plugin route access your
particular gateway and existing task state? Transport,
authentication and workspace availability can still block that. I have
not verified that your older Secure MCP setup transfers unchanged, and
these documents do not establish that the ordinary-Chat execution
failure is fixed.