Using claude code or custom Slash Commands with Claude Code ACP Integration

[iamthebot]

How do custom or built-in claude code slash commands (defined in claude code) work when using claude code via ACP? These work out of the box in Zed with the claude code ACP client; however, I'm not sure how to use them with codecompanion.

Eg; /cost doesn't do anything.

[iamthebot]

Doing some more research, this is handled in ACP via the available_commands_update session notification. This is not yet supported via gemini CLI but it is supported in claude code ACP.

Working on a PR to add this.

[olimorris]

Btw...if you're working in CodeCompanion locally, you can open a chat buffer and do /memory and you should see CodeCompanion/acp as an option. I've got some memory files which outline the ACP implementation in the plugin.

[iamthebot]

Nice! I'll go ahead and use this as I'm working on exposing commands more cleanly in the plugin.

[olimorris]

I replied to your issue and there's a lot that of slash commands that aren't in the Claude SDK to my knowledge but you're quite right I've not added support for slash commands in the UI. But that shouldn't stop you doing something like /review the most recent PR.

I think there's a few challenges to this because we may need to create a session on adapter initialization in order to return the available slash commands (https://agentclientprotocol.com/protocol/slash-commands#advertising-commands). And probably fire an event to update the slash commands.

[iamthebot]

@olimorris so, I did a lot of digging and indeed the story today is kind of complicated.

I studied some traffic replay as I interacted with claude code in an ACP session to verify the below:

1. As you noted (and is referenced in some slash commands not available zed-industries/claude-code-acp#33) The underlying SDK (eg; claude code SDK) has to implement each command. Funny enough looks like user commands do get announced at the start of the ACP session but built-ins rely on the claude code SDK adding support for them. Eg; /compact is already implemented.
2. On start, we get a notification structure like:

  {
    "sessionUpdate": "available_commands_update",
    "availableCommands": [
      {
        "name": "global:community:fetch-upstream",
        "description": "Fetch upstream, rebase, test and push (project, gitignored)",
        "input": null
      },
      {
        "name": "compact",
        "description": "Clear conversation history but keep a summary in context...",
        "input": { "hint": "<optional custom summarization instructions>" }
      }
    ]

So what I'm trialing out in a PR is the following approach:

When in a chat buffer and we initiate an ACP session, we capture the available_commands_update and cache the available commands. But since there's no guarantee that commands won't conflict with builtins, we instead use \ (backslash, I've made this configurable though) for ACP commands. Unlike built-ins that get executed immediately, we make ACP commands available in completion and insert them in the chat buffer as-displayed (using eg; backslash).

During the send, we replace backslash-prefixed ACP commands (we have the list so we can do it accurately) with their / equivalents. These are just sent as text though (verified Zed does the same thing).

This give us the benefit of ACP command completion without risk of command collision with codecompanion builtins. Also, as underlying ACP clients/SDKs get updated we can immediately leverage those new commands.

[iamthebot]

PR for those interested: #2260 . It's working quite well! Just cranked out an internal PR using the ACP integration with completions and custom commands