Cursor ACP: session/load fails with Session "<id>" not found, breaking persistent sessions (acpx/OpenClaw ACP runtime)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

  • Cursor CLI（specifically Cursor CLI’s ACP server: cursor-agent acp / agent acp）

Describe the Bug

  • When using Cursor CLI’s ACP server for persistent ACP sessions, session/load fails with Invalid params → Session "<id>" not found, even though the session was just created (via acpx ... sessions new/ensure).

  • This breaks orchestrators like acpx/OpenClaw ACP runtime, causing stalls and eventually acpx exited with code 1 / ACP_TURN_FAILED.

  • One-shot mode (acpx cursor exec ...) works.

Steps to Reproduce

  1. Start / ensure Cursor ACP server is available (Cursor CLI installed & logged in):

  • cursor-agent login (if needed)

  • ACP server is launched implicitly by acpx/OpenClaw; or run cursor-agent acp to verify it starts.

  1. Create a persistent session with acpx:
  • acpx cursor sessions new --name test-session
  1. Prompt the session (or run via stdin):
  • echo 'Reply with exactly CURSOR_PROMPT_OK' | acpx --format json --json-strict --cwd <any> cursor prompt --session test-session --file -
  1. Observe failure: acpx sends session/load with the returned sessionId, but Cursor ACP responds Session "<id>" not found. acpx exits non-zero.

Expected Behavior

  • After creating/ensuring a session, session/load should successfully load that session and allow subsequent prompt calls to continue the conversation (multi-turn persistence), without errors or stalling.

Screenshots / Screen Recordings

  • Not required; attaching logs is more useful.

  • Attach: acpx NDJSON stream showing the JSON-RPC exchange and the session/load failure (I have a zip bundle with *.stream.ndjson, plus OpenClaw error snippet).
    cursor-acp-sessionload-fail-20260322.zip (5.9 KB)

Operating System

  • Linux

Version Information

CLI:

  • Cursor CLI / cursor-agent version: 2026.03.20-44cb435 (cursor-agent --version)

  • (Optional context) OpenClaw: 2026.3.13

  • acpx: 0.1.16

For AI issues: which model did you use?

  • N/A (protocol/session management issue, not model-specific)

Additional Information

  • acpx cursor exec "..." (one-shot) works reliably because it uses session/new and does not depend on session/load.

  • The failing path is persistent session management requiring session/load.

  • Attached logs show initialize succeeds and advertises loadSession: true, but session/load fails for the returned sessionId.

Does this stop you from using Cursor?

  • Sometimes — Cursor CLI works for one-shot, but ACP persistent sessions (and tools relying on them, e.g. OpenClaw /acp spawn cursor) are not usable.

Questions

  1. Is Cursor’s ACP implementation expected to support session/load for sessions created via ACP?
  2. If so, what is the correct session id to use (agent session id vs acpx record id)? Right now the id returned by acpx cursor sessions new cannot be loaded.
  3. Any known minimum Cursor version that fixes this?
2

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)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere 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!

  1. …
  2. …
  3. …

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!

7

Hey, thanks for the detailed bug report. The logs and repro steps are super helpful.

I’ve flagged this with the team. session/load returning “Session not found” right after a successful session/new does look like a bug on our side, especially since the server reports loadSession: true during initialize.

A couple quick questions that’ll help us debug faster:

  1. In the NDJSON logs, is the sessionId you pass to session/load the same one you got back from session/new? I just want to rule out any ID mapping issue between acpx and the ACP server.
  2. Have you tried calling session/load directly using raw JSON-RPC, without acpx, to confirm it’s not acpx-specific?

For now, one-shot mode via exec is the workaround like you mentioned. No ETA on a fix yet, but your report helps us prioritize this. I’ll post an update here if there’s news.

9

Hi, update — I’ve reproduced the issue with raw JSON-RPC (no acpx involved).

Root cause: The session/load call fails immediately after session/new returns a valid sessionId.

Test script:

# Initialize
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1}}' | cursor-agent acp

# Create session (capture first line only, skip subsequent notifications)
SESSION_ID=$(echo '{"jsonrpc":"2.0","id":2,"method":"session/new","params":{"cwd":"'$PWD'","mcpServers":[]}}' | cursor-agent acp | head -n1 | jq -r '.result.sessionId')
# Returns: "13631a3d-b19f-4fad-b3ef-4f65732113d5"

# Load session immediately (same ID)
echo '{"jsonrpc":"2.0","id":3,"method":"session/load","params":{"sessionId":"'$SESSION_ID'","cwd":"'$PWD'","mcpServers":[]}}' | cursor-agent acp
# Returns: Session "13631a3d-b19f-4fad-b3ef-4f65732113d5" not found

Answers to your questions:

  1. :white_check_mark: Yes, sessionId passed to session/load is exactly the same one returned from session/new
  2. :white_check_mark: Raw JSON-RPC confirms: This is a Cursor ACP server bug. The session becomes “not found” immediately after creation, even when called in the same shell pipeline (<100ms apart).

Additional finding: session/new emits a follow-up session/update notification. If you’re parsing the output, make sure to only process the first JSON line for the response.

Let me know if you want me to test anything else!

10

Any progress? I’m using the Cursor ACP agent in Discord and ran into the same issue.