@cursor/sdk 1.0.35 + Grok 4.6 high: isolated no-tool runs drop or die with [internal] unable to open database file (2026-10-02)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Where does the bug appear: Cursor SDK (@cursor/sdk), not the IDE chat.

On 2026-10-02, local Agent.create → send → wait() runs with Grok 4.6, effort: high, fast: false fail in two ways while status.cursor.com is All Systems Operational and the IDE chat on the same account works.

Linux VPS (Node 22, sequential isolated agents, tools: , empty temp cwd, new agent per call):
Agent turn stopped after repeated resume attempts made no progress
Connection failed repeatedly
Same adapter, same model, previous day (2026-10-01) finished a 19-call batch around 08:41. Bumping @cursor/sdk 1.0.30 → 1.0.35 did not stop the drops.

Windows, same adapter, one-line prompt {“ok”:true}: sandbox fallback, then fail after 145s with
Cursor non ha risposto: [internal] unable to open database file.
run.cancel() after 8s does resolve wait() with status: cancelled.

Expected: a no-tool isolated agent returns text (or a structured error with run.id) in the usual couple of minutes, including for a one-line JSON prompt. Status green / IDE chat healthy should not hide a broken SDK stream.

This is not a huge-payload / long-lived conversation case: each run is a fresh agent, no tools, tiny prompt. Happy to add agent.agentId / run.id from the next failure.

Steps to Reproduce

  1. Node 22, @cursor/sdk 1.0.35 (also seen on 1.0.30). CURSOR_API_KEY of a Pro account that can select Grok 4.6.
  2. Run this as a one-shot. Fresh agent, empty temp cwd, tools: , Grok 4.6, effort high, fast false:
import { mkdtemp } from "node:fs/promises";
import { tmpdir } from "node:os";
import { join } from "node:path";
import { Agent, Cursor } from "@cursor/sdk";
const apiKey = process.env.CURSOR_API_KEY!;
const models = await Cursor.models.list({ apiKey });
const grok = models.find((m) => /grok-4\.6/i.test(m.id) || /grok-4\.6/i.test(m.name ?? ""));
if (!grok) throw new Error("grok-4.6 not in catalog");
const cwd = await mkdtemp(join(tmpdir(), "probe-"));
const agent = await Agent.create({
  apiKey,
  model: {
    id: grok.id,
    params: [
      { id: "effort", value: "high" },
      { id: "fast", value: "false" },
    ],
  },
  mode: "agent",
  tools: [],
  local: { cwd, settingSources: [], sandboxOptions: { enabled: false } },
});
const run = await agent.send('Reply with JSON only: {"ok":true}');
const result = await run.wait();
console.log(result.status, result.error, result.result);
await agent[Symbol.asyncDispose]();

Windows: after the usual sandbox-not-supported fallback (if you leave sandbox on), wait() fails after ~145s with [internal] unable to open database file. A one-line JSON prompt should not take that long or die on SQLite.

Linux VPS, same options, new agent per call, sequential: wait() ends with Agent turn stopped after repeated resume attempts made no progress or Connection failed repeatedly. Same machine + adapter on 2026-10-01 finished a 19-call batch around 08:41. Status.cursor.com was green; IDE chat on the same account worked.

Bumping @cursor/sdk 1.0.30 → 1.0.35 did not stop the Linux drops.





### Operating System
Linux

### Version Information
cursor sdk 1.0.35







### Does this stop you from using Cursor
No - Cursor works, but with this issue
5

Local Windows repro just now (2026-10-02 12:26:55 send, 12:29:12 error, ~137s):

agentId: agent-acea4caa-1981-4805-992f-a3551f08bbd8

runId: run-be986a44-47f2-4991-af5d-259720a334ec

requestId: bb5b52f9-4b23-4a87-992a-15d25381f54f

status: error

error: [internal] unable to open database file

7

Hey @mad4thrash, thanks for the report and the repro script.

From what we can see, the model side of these runs finishes normally. The failure happens when the SDK saves the run’s progress into its local SQLite store on your machine (under ~/.cursor/projects/.../sdk-agent-store). unable to open database file is SQLite on your side refusing to open that file, so the run can’t save a checkpoint, retries the same turn, and eventually stops with the “resume attempts made no progress” or “Connection failed repeatedly” errors.

Could you try the file-based store instead, with a short path? Run this once before Agent.create:

import { Cursor, JsonlLocalAgentStore } from "@cursor/sdk";
Cursor.configure({ local: { store: new JsonlLocalAgentStore("/var/tmp/cursor-sdk-store") } });

On Windows, use something short like C:\cursor-sdk-store. The default store path includes your temp folder name plus two long hashes, and on Windows it can run into the 260 character path limit.

If it still fails, please send:

  1. agent.agentId and run.id from a failed run
  2. On the VPS, the output of df -h ~, df -i ~, ulimit -n and ls ~/.cursor/projects | wc -l (each new temp cwd creates a new folder there)
  3. Whether your adapter sets its own timeout or AbortSignal around send() / wait(), since some runs are being closed from the client side after 45 seconds to 2 minutes
9

Hey, thanks for the diagnosis.

It matches what I saw on Windows. Same adapter, one-line {"ok":true}, Grok 4.6 high, Fast off, tools: []. On the default SQLite store the first thinking-delta arrived at about 4s, then the same turn repeated at 3.5s, 37s, 71s and 110s, and wait() ended at 141s with status=error and [internal] unable to open database file. With JsonlLocalAgentStore it was one turn and finished with {"ok":true} in about 4.6s. That failed Windows run was agentId agent-acea4caa-1981-4805-992f-a3551f08bbd8, runId run-be986a44-47f2-4991-af5d-259720a334ec, requestId bb5b52f9-4b23-4a87-992a-15d25381f54f.

The VPS is Linux, so the 260-character path limit is not that machine. Yesterday there I mostly saw Agent turn stopped after repeated resume attempts made no progress and Connection failed repeatedly, almost never the SQLite string. Today the same host finished about 60 isolated agent calls in 2.5–3 hours, roughly 2.5–3 minutes each, which is the healthy rate.

On the VPS, df -h ~ is /dev/sda1 96G, 23G used, 73G free, 24%. df -i ~ is 12,976,128 inodes, 561,210 used, 5%. ulimit -n is 60000. ls ~/.cursor/projects | wc -l is 49. Disk, inodes and the fd limit look fine; 49 project folders is not a pile-up.

Yes, the adapter closes runs from the client. There is no AbortSignal on send(). I call run.cancel() myself: 10 minutes on wait() as a backstop, 2 minutes with no thinking / thinking-delta then a new agent, and 5 seconds after turn-ended then cancel() and I keep the streamed text if I already have it. The 45s–2min closes you are seeing are those client timers, not the model hanging up. The 5s-after-turn one in particular aborts a wait() that may still be retrying the local checkpoint.

I will surely try Cursor.configure({ local: { store: new JsonlLocalAgentStore(...) } }) if SQLite fails again.