Python SDK: every Agent/Cursor call crashes with WinError 10038 on native Windows (Bridge discovery uses selectors.select() on pipe handles)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Any cursor_sdk call that reaches the module’s default-client bootstrap (Agent.prompt(…), Agent.create(…), even the runtime-agnostic Cursor.models.list()) crashes on native Windows Python with:

OSError: [WinError 10038] An operation was attempted on something that is not a socket

Root cause, read from the installed package source: Bridge.launch()'s discovery step registers the launched subprocess’s pipe file descriptors into a selectors.DefaultSelector() and calls .select() on it. Python’s select()/selectors implementation on Windows only accepts real socket objects – pipe handles aren’t interchangeable with sockets on Windows the way they are on POSIX.

This is unconditional: it happens during bridge startup/discovery, before any local= vs cloud= branch is evaluated. So it isn’t something a caller can dodge by picking cloud mode instead of local mode from a Windows machine – every SDK entry point is blocked on native Windows regardless of runtime choice.

Steps to Reproduce

  1. pip install cursor-sdk (1.0.30) on a native Windows 10/11 Python 3.11+ install (not WSL, not a container)
  2. from cursor_sdk import Agent, AgentOptions, LocalAgentOptions
  3. Agent.prompt(“hello”, AgentOptions(api_key=…, model=“composer-2.5”, local=LocalAgentOptions(cwd=“.”)))
  4. Crashes with WinError 10038 before the prompt is ever sent

Control: the exact same code, same model, same prompt, run on a Linux host (not WSL, a separate machine) completes cleanly end-to-end. This isolates the bug to the Windows-specific code path in Bridge.launch()'s discovery/select loop, not anything else in the call.

Expected Behavior

Agent.prompt / Agent.create / Cursor.models.list should work on native Windows Python the same way they do on Linux/macOS, without a WinError 10038 during bridge discovery.

Operating System

Windows 10/11

Version Information

SDK: cursor-sdk (Python) 1.0.30, installed via pip on 2026-08-27/30
Python: 3.11 (native Windows install, not WSL)
OS: Windows 10/11

Additional Information

Not a model/AI-reasoning bug – it’s a pure client-bootstrap failure before any prompt is sent, so ‘model used’ / ‘request ID’ fields above don’t really apply here. Happy to share the full traceback or a minimal repro script if useful.

Ask: either swap the discovery wait mechanism to something Windows-compatible for pipe handles (e.g. msvcrt/ctypes overlapped I/O, or a thread-based readline loop instead of selectors.select()), or – if a near-term fix isn’t planned – document native Windows as currently unsupported for the Python SDK so the next person doesn’t spend a debugging session rediscovering this from a raw traceback.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @Troy_Bourque, thanks for the report.

You’ve read it right: the sync client’s startup path waits on the helper process’s pipe in a way Windows doesn’t support, so every sync entry point fails there before any request is sent. This is a known issue we’re already tracking, and I’ve added your report to it.

In the meantime, the async API takes a different startup path that doesn’t have this problem, so it should work on native Windows:

import asyncio
from cursor_sdk.asyncio import AsyncAgent, AsyncClient

async def main():
    async with await AsyncClient.launch_bridge(workspace=".") as client:
        agent = await AsyncAgent.create(client=client, model={"id": "composer-2.5"})
        ...

asyncio.run(main())

Running under WSL is another option if you need the sync API.