[Bug]: Cursor thread titles never generate on Windows: the sandbox fallback catches Agent.create, but SDK 1.0.38 throws from agent.send #27702

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: Cursor threads fail to start on Windows in any runtime mode except Full access ("Local SDK sandboxing was requested, but sandboxing is not supported") #15901 (closed by fix(provider-cursor): start default Cursor threads on Windows #20046) fixed the same SDK error for Cursor thread startup in adapter.ts, but not for text generation. fix(server): retry Cursor text generation without sandboxing #13863 added the text-generation retry this issue is about.
• I included enough detail to reproduce or investigate the problem.

Area

packages/provider-cursor (text generation: thread titles, and likely commit, PR and branch text)

Steps to reproduce

1. On Windows, enable only the Cursor provider and sign in.
2. Leave Settings → Text generation model on a Cursor model (reproduced with glm-5p3-flash).
3. Start a thread with any first message, or right-click an existing thread and choose "Regenerate title".

Expected behavior

On Windows, where the Cursor SDK cannot sandbox the filesystem, title generation falls back to an unsandboxed run in its empty temp directory (the retry from #13863) and the thread gets a generated title.

Actual behavior

No title is ever generated. Every thread keeps its truncated first message as the title. "Regenerate title" does nothing visible. The server log shows Thread title generation failed with Cursor SDK text generation failed.

Root cause

runCursorJson in packages/provider-cursor/src/server/textGeneration.ts (same on main at 028ed85) requests sandboxOptions: { enabled: true } and retries without the sandbox only when Agent.create fails:

const agent = yield* Effect.acquireRelease(
  createCursorAgent(true).pipe(
    Effect.catchIf(cursorSandboxUnsupported, () => createCursorAgent(false)),
  ),
  ...
);
const run = yield* Effect.tryPromise((signal) => agent.send(prompt)...);

With @cursor/sdk 1.0.38 (the version pinned on main and shipped in 0.1.5), Agent.create succeeds. The sandbox check runs lazily when the executor is built inside agent.send, so the ConfigurationError is thrown outside the catchIf and the fallback never runs. The stack trace below goes vt.send → vt.sendImpl → vt.getExecutor → ConfigurationError.

The unit test continues in the temp directory when the SDK cannot sandbox in textGeneration.test.ts mocks cursorSdkMock.create to throw, so it passes even though the real SDK throws from send.

Suggested fix

Either of these:

• Retry the whole create-and-send step (create, send, and if needed wait) with sandboxOptions: { enabled: false } when cursorSandboxUnsupported(cause) matches, and change the test so the mocked send throws the sandbox error.
• Skip the sandbox request on win32 for text generation, as fix(provider-cursor): start default Cursor threads on Windows #20046 did for the session adapter (cursorRuntimeAgentPolicy). Text generation already runs in an empty temp cwd with settingSources: [], so the code comment notes it stays isolated even without the sandbox.

Impact

Major degradation. On Windows, a Cursor-only setup never gets generated thread titles, and manual "Regenerate title" also fails. There is no workaround within T3 other than adding another provider or renaming threads by hand.

Version or commit

T3 Code (Beta) 0.1.5 desktop, server 0.1.5, @cursor/sdk 1.0.38. Code unchanged on main at 028ed85.

Environment

Windows 11 (10.0.26300) x64. Desktop app. Only the Cursor provider is enabled. Text generation model: cursor / glm-5p3-flash. There is no ~/.cursor/sandbox.json; ~/.cursor/cli-config.json has sandbox.mode: "disabled". Neither matters, because T3 sets sandboxOptions explicitly.

Logs or stack traces

In server.trace.ndjson, all 10 CursorTextGeneration.generateThreadTitle spans failed with this cause, and none succeeded:

TextGenerationError: Text generation failed in generateThreadTitle: Cursor SDK text generation failed.
    at CursorTextGeneration.runCursorJson (...)
    at CursorTextGeneration.generateThreadTitle (...)
    at TextGeneration.generateThreadTitle (...)
    at ThreadTitleRegenerationService.execute (...) {
  [cause]: UnknownError: An error occurred in Effect.tryPromise {
    [cause]: ConfigurationError: Local SDK sandboxing was requested, but sandboxing is not supported in this environment. Disable local.sandboxOptions.enabled or remove ~/.cursor/sandbox.json to run without sandboxing.
        at r.apiKey.cwd (...\node_modules\@cursor\sdk\dist\cjs\748.js:1:981086)
        at fR (...\node_modules\@cursor\sdk\dist\cjs\748.js:1:981452)
        at async Bt (...\node_modules\@cursor\sdk\dist\cjs\index.js:1:2279718)
        at async vt.getExecutor (...\node_modules\@cursor\sdk\dist\cjs\index.js:1:2290627)
        at async vt.sendImpl (...\node_modules\@cursor\sdk\dist\cjs\index.js:1:2284788)
        at async vt.send (...\node_modules\@cursor\sdk\dist\cjs\index.js:1:2280634)
  }
}

Workaround

Rename threads by hand, or set Settings → Text generation model to a non-Cursor provider if one is installed.