Google Drive MCP fails in Cursor SDK after CLI login and full T3 restart

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Google Drive tool discovery fails in the Cursor SDK local runtime used by T3 Code, even though the standalone Cursor Agent CLI confirmed successful authentication and listed 19 enabled Drive tools. The failure persisted after fully quitting and reopening T3.

The affected namespace is plugin-google-drive-google-drive. It returns namespaceStatus: error and only exposes mcp_auth. The exact message is:

This MCP server failed during live tool discovery. Its tools are unavailable until the connection is fixed.

No metadata tool was callable, so no Drive file read was attempted. No HTTP status, JSON-RPC code, or specific OAuth failure was exposed. Successful CLI sign-in and tool visibility are separate from successful SDK access.

Steps to Reproduce

  1. Enable the official Google Drive plugin in Cursor. Desktop inspection showed 19 enabled tools.
  2. From the same project directory used by the T3 session, open the standalone Cursor Agent CLI, run /mcp, select Google-drive, and complete Login. It confirmed Authenticated MCP server 'Google-drive' and showed 19 enabled tools.
  3. Start a fresh Cursor session in T3 Code in that same directory and request Drive tool discovery. It fails with the error above and exposes only mcp_auth.
  4. Fully quit and reopen T3 Code, then repeat discovery once in a fresh Cursor session in the same directory. The same failure remains.

Latest restart evidence: the T3 application and child processes started on November 8, 2026 at approximately 8:59 p.m. Central (November 9, 02:59 UTC). The fresh check recorded at 9:04 p.m. Central (03:04 UTC) still returned namespaceStatus: error, only mcp_auth, and no metadata tool. A later process check corroborated the reported restart; the diagnostic did not capture an exact mapping from the failed session to a process ID.

Earlier checks also included closing Cursor desktop/helpers/CLI and verifying that a separately relaunched interactive CLI still listed 19 Drive tools. Closing those processes did not repair T3 discovery.

Expected Behavior

The SDK session should load the authenticated Google Drive plugin with callable read tools, allowing a read-only metadata request. If discovery fails, it should expose an actionable error or a supported way to retrieve the underlying HTTP/JSON-RPC failure.

Operating System

MacOS

Version Information

macOS, Apple Silicon
Cursor Desktop: 3.29.14 (commit 39a0976a51355951e1f4ffe5777b3bbc2c00f050)
Cursor Agent CLI: 2026.11.05-86047df (@anysphere/agent-cli-runtime)
T3 Code: 0.1.7
Bundled @cursor/sdk: 1.2.0
Google Drive plugin: 1.0.1
Provider protocol: cursor-agent-sdk.local
Plugin endpoint: https://api.cursor.com/rest-mcp/google-drive/mcp

For AI issues: which model did you use?

Cursor Auto/default in T3; the observed failure is MCP tool discovery before any Drive file read.

Additional Information

I initially reported this to T3: [Bug]: Cursor SDK local Google Drive MCP discovery fails while desktop and CLI list tools · Issue #33156 · pingdotgg/t3code · GitHub

The maintainer traced the issue to Cursor’s SDK and closed it as upstream: [Bug]: Cursor SDK local Google Drive MCP discovery fails while desktop and CLI list tools · Issue #33156 · pingdotgg/t3code · GitHub

Their response explains that the SDK reads the same per-project plugin authentication state written by CLI Login, caches it once per process, and requires a full T3 server restart to pick up a login performed while T3 is running. The latest check above still failed after reopening T3. SDK authentication success remains unverified locally; a stale process cache has not resolved this case.

Local source and provider logs identify T3’s path as Agent.create with the local runtime and setting sources project, user, team, mdm, plugins. T3 injects its own MCP server; the Cursor SDK handles plugin loading and Drive discovery. The maintainer also reports that the SDK records the detailed discovery failure internally but omits it from the message T3 receives.

Could Cursor provide:

  1. The underlying HTTP status, JSON-RPC code, or toolListError descriptor for this SDK-local Google Drive discovery failure?
  2. A supported way to retrieve that diagnostic without exposing credentials or unfiltered logs?
  3. The supported remedy when same-directory CLI Login succeeds but SDK discovery still fails after a full host restart?

Related Cursor staff discussion about desktop versus CLI plugin sign-in: Some plugins that work in the desktop app can't be used from the CLI agent

No credentials, authorization headers, private Drive file IDs, raw logs, or personal filesystem paths are included in this report.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hi @Meh-S-Eze, your Google sign-in isn’t the problem, and another login or restart won’t change this.

The Google Drive plugin runs through a Cursor-hosted server that needs your Google sign-in plus a Cursor credential on every request. The SDK’s local runtime doesn’t send that Cursor credential yet. The desktop app and an interactive CLI agent session do, so Drive works there but not in T3. I’ve passed this to the team.

From what I can see the server is rejecting the request as unauthenticated (an HTTP 401). There isn’t a supported way to get that detail out of the SDK today.

In the meantime, Drive works from the Cursor desktop app or from an interactive CLI session (agent in your project folder) on the same machine.