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
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.
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)
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
Is Cursor’s ACP implementation expected to support session/load for sessions created via ACP?
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.
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, 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:
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.
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.
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:
Yes, sessionId passed to session/load is exactly the same one returned from session/new
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.
Are you guys also looking at making Cursor chat and agent compatible with ACP as its own client? That would allow us to do fully-detached IDE which would be quite useful for offline work, everything would run on server e.g. through SSH or tunnel
It would require upon reconnecting that it resyncs the UI with the current state, but I can’t imagine this would be difficult to do internally since you guys have access to the codebase, it would mainly just have to save states in the SQL3 DB wherever the ACP is running and a local copy and sync, with agent←>environment communication done over ACP
Basically, make Cursor chat and agent in the IDE full ACP-compatible clients with your guys’ own internal features and have a host, client DB that syncs based on host state, if you guys use Yjs CRDT it should handle conflicts
Hey @Eduard, interesting idea, but it’s basically a separate feature request and not related to the session/load bug in this thread. I’d recommend starting a new topic in the Feature Requests category Feature Requests - Cursor - Community Forum and describing your use case so the team will definitely see it and can prioritize it.
On the main bug session/load returning “Session not found”, sadly there’s no news yet. The team is aware, but there’s no ETA. I’ll update the thread if anything changes.
Yes, sessionId passed to