Using Auto mode, after some time the provider error appears. Closing and reopening Cursor fixes it temporarily

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When connected to MCP server which is sqlcl (oracle) I am getting this error consistantly. When I log out and come back in, it works temporarily, but pops this error again. It used to work fine until a few days back. I use that a lot. Any help appreciated
Request ID: c0de4d1e-eb7c-49cb-9df6-17141a32af61
{“error”:“ERROR_PROVIDER_ERROR”,“details”:{“title”:“Provider Error”,“detail”:“We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
TAi: Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
at n5A (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34249:23670)
at e5A (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34249:22658)
at l5A (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34250:6285)
at _ou.run (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34250:10400)
at async vOa.runAgentLoop (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46813:9906)
at async I3u.streamFromAgentBackend (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46867:9277)
at async I3u.getAgentStreamResponse (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46867:13639)
at async bMe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:34310:17597)
at async Object.nc [as onSubmit] (vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:45792:4828)
at async vscode-file://vscode-app/c:/Program%20Files/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:45766:56558

Steps to Reproduce

Every time I enable the MCP server

Expected Behavior

It should connect to the database

Operating System

Windows 10/11

Version Information

Version: 2.6.11 (system setup)
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: which model did you use?

Auto

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the report. This is a known situation. MCP servers can trigger provider errors when you’re in Auto mode. Here are a few things to try:

  1. Temporarily disable the sqlcl MCP server in Cursor Settings > Tools & MCP, then start a new chat. This has helped most users with the same error. If the chat works without the MCP server, that confirms the source.

  2. Disable HTTP/2: Cursor Settings > Network > turn on “Disable HTTP/2”. Since you’re on a Team plan, your corporate network or proxy might be interfering.

  3. Run network diagnostics: Cursor Settings > Network > Run Diagnostics, then share the results here.

A couple quick questions to narrow it down:

  • Does the error happen with all models, or only in Auto mode? Try switching explicitly to GPT to test.
  • Are you using a VPN or a corporate proxy (like Zscaler)?
  • How long does it work after a restart before the error comes back?

Let me know what you find.

4

Hi,

  1. If I disable the MCP server, it works. But connect to the database is what I am trying to do.
  2. I dont see an option to disable HTTP/2
  3. All diagnostics run fine.

I tried selecting individual models and it’s the same effect for all
We do use a VPN to connect to the database, But it has been working flawlessly for a long time.
If I close and restart it works for the first time. Any subsequent follow up fails

image
image722×300 10.4 KB

5

Hey, a couple of things based on your reply:

The HTTP/2 option is the dropdown you see in your screenshot. “HTTP Compatibility Mode” is currently set to “HTTP/2”. Try switching it to HTTP/1.1 in that dropdown, then restart Cursor. Since you’re on a VPN, it’s worth testing.

The pattern you described, it works once after a restart, then fails on the next requests, suggests the MCP transport connection is getting stuck after the first session. A few things to try:

  1. Switch the dropdown to HTTP/1.1 and restart.
  2. Update to the latest Cursor version. You’re on 2.6.11 from March 3, and there have been fixes for provider errors in Auto mode since then.
  3. Can you share your MCP server config? Specifically, what transport type does your sqlcl server use, stdio, sse, or http? You can find this in .cursor/mcp.json or in Cursor Settings > Tools & MCP.

The team knows about MCP transport stability issues in this area. Your report helps us prioritize, especially the “works once then breaks” detail.

Let me know how the HTTP/1.1 switch goes.

6

I have been playing around with that since you suggested that. Switching to 1.1 did not help. What helped was when I switched back to version 2.5 :slight_smile: . I have been having a relatively stable connection since I went back to this version. HTTP is still on 2. Rest everything is the same. Let me see if this eventually breaks or not.

Version: 2.5.26 (system setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

The jason file is this

{“mcpServers”: {
“sqlcl”: {
“command”: “C:\\oracle\\sqlcl\\bin\\sql.exe -mcp”,
“env”: {},
“args”: []
}
}
}

8

Well that didnt fix the issue..but is definitely stabler

9

Hey, thanks for the follow-up and for testing different versions. That’s really helpful data.

A couple of things:

First, your MCP config might have an issue. The command field should include only the executable path, and any arguments should go in the args array. Try this format:

{
  "mcpServers": {
    "sqlcl": {
      "command": "C:\\oracle\\sqlcl\\bin\\sql.exe",
      "args": ["-mcp"],
      "env": {}
    }
  }
}

If everything is in one command string, process spawning can act unpredictably, especially across versions. That could explain why it works once and then breaks.

Second, the team is aware of MCP transport stability issues in the 2.5 to 2.6 range. There’s no timeline for a fix yet, but your “works once then breaks” pattern is exactly the kind of detail that helps us prioritize.

For now, staying on 2.5.26 is a reasonable workaround if it’s more stable for you. After you fix the config format above, try updating to the latest version again and see if that helps.

If it still happens after the config fix, can you share a fresh Request ID from a failed request? That’ll help the team dig into your specific case.

10

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.