Cursor-sdk 1.0.24 on Windows: local bridge works but cloud Agents API returns HTTP 500 internal error

Cursor SDK returns HTTP 500 “internal error” for me() and list_models() on Windows

Where does the bug appear?

Cursor SDK (Python)

Version

  • cursor-sdk: 1.0.24
  • Python: 3.11.5 (AMD64)
  • Windows: 10.0.26200

Description

Using a valid User API Key from Cursor Integrations (crsr_...).

The local SDK bridge starts successfully:

  • Ping → 200 OK
  • GetVersion → 200 OK (bridge version 1.0.0)

However all cloud-backed SDK calls fail:

  • Client.me() → HTTP 500

  • Client.list_models() → HTTP 500

  • Error payload:

    {

    “code”: “internal”,

    “message”: “internal error”

    }

This occurs consistently on multiple days.

Reproduction

import os

from cursor_sdk import Client

client = Client.launch_bridge(workspace=“C:/temp/project”)

print(

client.me(

api_key=os.environ[“CURSOR_API_KEY”]

)

)

Actual Result

InternalServerError: internal: internal error

status=500

The same happens with:

client.list_models(…)

Additional Observation

A direct CreateAgent RPC test returns:

{

“code”: “invalid_argument”,

“message”: “cannot decode field sdk.v1.LocalAgentOptions.cwd from JSON”

}

when a Windows path is supplied with backslashes.

Expected Behavior

  • Client.me() should return account information.
  • Client.list_models() should return available models.
  • Agent.create() should either succeed or return a clear authorization/entitlement error.
  • Invalid permissions should return 401/403 rather than HTTP 500.
  • Windows path handling requirements should be documented if backslashes are unsupported.

Does this stop you from using Cursor?

Yes. All cloud-backed SDK operations currently fail.

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.


Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!


Expected Behavior
What is meant to happen here that isn’t working correctly?


Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)


Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)


For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…


Additional Information
Add any other context about the problem here.


Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

Hey @Prashant_Morade,

That internal: internal error 500 is masking the real failure. Your local bridge health checks (Ping, GetVersion) pass because they never leave your machine, but me() and list_models() have to reach Cursor’s backend over HTTPS, and that request is almost certainly being blocked by TLS inspection on your corporate network. The SDK runs a bundled Node runtime that doesn’t use the Windows certificate store by default, so behind a TLS-inspecting proxy its HTTPS call fails the cert check and surfaces as that generic 500 (which is why every cloud-backed call fails the same way).

To confirm and fix:

  1. Check reachability outside Node. From the same machine:
curl https://api.cursor.com/v1/me -H "Authorization: Bearer %CURSOR_API_KEY%"

If curl returns 200 but the SDK still 500s, it’s the bundled Node’s certificate trust, not your key or account.

  1. Quick diagnostic (don’t leave this on). Run your script once with TLS verification disabled:

set NODE_TLS_REJECT_UNAUTHORIZED=0 && python your_script.py

This disables certificate validation and is only meant to confirm the diagnosis. Turn it off again immediately after testing. If the 500 disappears, TLS interception is confirmed.

  1. Proper fix. Point the bundled Node at your corporate root CA (a .pem file):

set NODE_EXTRA_CA_CERTS=C:\path\to\corp-root-ca.pem

If your network also requires an outbound proxy, add:

set HTTPS_PROXY=http://your-proxy:port
set HTTP_PROXY=http://your-proxy:port
set NODE_USE_ENV_PROXY=1

(In PowerShell, use $env:NODE_EXTRA_CA_CERTS="C:\path\to\corp-root-ca.pem".) Your IT/security team can point you at the corporate root CA in PEM form.

On the CreateAgent observation: cannot decode field ...cwd from JSON with backslashes is coming from the raw RPC test, not the SDK. In JSON a Windows path needs escaped backslashes ("C:\\temp\\project") or forward slashes ("C:/temp/project"). The Python SDK serializes the path for you, so LocalAgentOptions(cwd=...) through the SDK doesn’t hit this.

You’re right that a valid key hitting a network problem should surface a clear error rather than a blanket 500, and improving that error propagation so it shows the real cause is something we’re already working on. But the corporate CA cert above is what will actually unblock you today.

Docs for reference: Cursor Python SDK.

Give the CA cert route a go and let me know if me() starts returning your account info. Happy to dig in further if it doesn’t.