Update cursor to use official ACP

[Lenbok]

Cursor now has official ACP support: https://cursor.com/docs/cli/acp
We should use that rather than the third party acp adapter (which is limited in functionality and seems to have regular auth issues).

Checklist

• I agree to communicate with the author myself (not AI-generated).
• I've read the README's Filing issues section.
• I'm running the latest versions (fill in below).
  • agent-shell:
  • acp.el:
  • ACP package (e.g. claude-code-acp):
  • Agent CLI (e.g. claude, gemini):
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package.
• For issues, I'm including ACP traffic (as per README).

[Lenbok]

(BTW, I'm taking a look at implementing this, and will give it a run locally)

[xenodium]

(BTW, I'm taking a look at implementing this, and will give it a run locally)

Thanks!

[0x6362]

I started on an implementation of this and there's a few gotchas I'm not sure how @xenodium would want to handle and likely merit further discussion -- I admittedly didn't spend a ton of time deep diving into this since I've only made a small, minimal patch that gets things working with authentication and the default Agentic mode. See #393.

Small issues:

• the ACP server didn't seem to be properly updating me on when it made some changes, but I only experimented very briefly and it's likely a PEBKAC error (though I've not seen this same bug with Codex in my more extensive usage). I'll try and develop a minimal repro case and provide logs.
• The official server doesn't expose the modes/models available. I only noticed this issue on the availability after I'd written a patch to support passing the default model ID to the third party Cursor ACP server. I've excluded that code for now as it only creates an error

The big one are the custom Cursor ACP messages such as _cursor/update_todos:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "_cursor/update_todos",
  "params": {
    "toolCallId": "tool_$UUID",
    "todos": [
      {
        "id": "1",
        "content": "Fix authenticate method-id to cursor_login for API key case",
        "status": "in_progress"
      },
      {
        "id": "2",
        "content": "Add --api-key command-line support per Cursor docs",
        "status": "pending"
      },
      {
        "id": "3",
        "content": "Add tests for agent-shell-cursor API key",
        "status": "pending"
      }
    ],
    "merge": false
  }
}

The short term fix is to add code to filter these out, the more interesting thing would be to bring them into the viewport or comint window as an org mini-region, or some other UX.

The others are:

cursor/ask_question	Ask users multiple-choice questions
cursor/create_plan	Request explicit plan approval
cursor/task	Notify client about subagent task completion
cursor/generate_image	Notify client about generated image output

I couldn't get these to pop up in my short testing and didn't see docs from Cursor; once I can do that do I'll update the issue with schemas so UX for each can be discussed.

[Lenbok]

The approach I took in #394 is to extend the unhandled incoming request logic to send an error response (-32601 "Method not found") back to the server, and that prevents the agent-shell session from hanging.

https://forum.cursor.com/t/please-add-model-advertising-to-the-acp/154153 has someone else asking for cursor to support model selection in ACP - not sure how much they actually monitor forums though.

[0x6362]

I think in addition to sending an error response (for now), exposing something like a :custom-request-handlers key in agent-shell-make-config that takes a map of custom events and event handlers might be more extensible? I was able to hack in support for rendering tasks to Markdown inline (and then subsequently broke it), but have an example with create_plan in my branch

[Lenbok]

@0x6362 Yeah, custom request handlers seems like the way to go in terms of allowing support for such ACP server specific functionality (or perhaps handling server specific quirks). I think it kind of sucks that cursor started down this path. (BTW, I think your branch is missing the definition of agent-shell--send-unhandled-request-response (and once it's there, it could be made use of in your demo handler).

It looks like our PRs mostly differ in term of the auth handling (mine aims to handle the pre-auth and via token options, and passes them to the agent via vars rather than modifying cli args), but I'm happy to let you run with the PR process rather than us both tackling the same problem in two separate PRs.

[xenodium]

Thank you both!

The approach I took in #394 is to extend the unhandled incoming request logic to send an error response (-32601 "Method not found")

Let's go with this initially to unblock migration if possible.

I think in addition to sending an error response (for now), exposing something like a :custom-request-handlers key in agent-shell-make-config

It's unfortunate they're going in this direction. I've been through AI API fragmentiation in chatgpt-shell and was highly wasteful re-implementing things differently for every provider. I've been very happy with ACP in this regard (standardization).

Lemme have a think about how to start enabling these provider-specific handling. In the meantime, if you reckon the official Cursor ACP client (replying with -32601) is on par with what we have, we can look at swapping.

[0x6362]

It's unfortunate they're going in this direction. I've been through AI API fragmentiation in chatgpt-shell and was highly wasteful re-implementing things differently for every provider. I've been very happy with ACP in this regard (standardization).

With you there on the disappointment - nothing I've seen in the custom methods so far seems to do anything particularly novel - plan in particular seems to only be emitted so that the VSC fork knows it can be saved to .cursor and is otherwise the same as any other session/update call.

Running logging today and will see if I can provide samples of the rest of the custom methods - perhaps it's possible to avoid custom logic for most.

Lemme have a think about how to start enabling these provider-specific handling. In the meantime, if you reckon the official Cursor ACP client (replying with -32601) is on par with what we have, we can look at swapping.

In my testing so far Cursor's implementation is less prone to throwing spurious auth errors, e.g. when a model disabled by account policy is selected… but the bugs in the third party adapter can be fixed, whereas it's yet to be seen whether Cursor will improve their official offering or merely break it in new, exciting ways as they seem to frequently do with their VSC fork 😅.

@Lenbok thank you for the feedback, and apologies for the omission - I've been poking away at this between CI runs and am admittedly extremely rusty w. emacs/elisp in general. I switched for org-mode and cider only ever learned enough elisp to get by so my dev workflow is awful. Something firing in my emacs-lisp-mode keeps relinting the file and I missed adding those lines in the commit between all the whitespace spam.

[Lenbok]

BTW @0x6362 , as of cursor cli 2026.03.11-6dfa30c there is now the expected list of models being returned.

[0x6362]

And there's also this lib, which layers itself on top of the official ACP server to add some of the missing functionality.

I'm going to continue hacking away on my fork while xenodium figures out how they would like to handle this in the long run.