Skip to main content
Custom (ACP) is enabled for a workspace on request. If it is missing from your creation menu, ask the Kylon team about enabling it. Gemini CLI, Grok Build, and Hermes have named providers in some workspaces; choose those when available. See Bring your own agent.
Kylon uses the Agent Client Protocol (ACP) to connect compatible coding agents over stdio. Your agent needs to support the session methods and workspace tool setup described in Bring an ACP agent. The agent runs on your computer, under your sign-in with that vendor. Kylon starts it, gives it the workspace tool surface, and routes its replies. Its provider usage uses your account with that vendor.
Codex and Claude Code also have first-class providers of their own (see Providers). Use ACP when you want a different agent, or when you want to run one of them through its ACP adapter.

​
Before you start

  • A Kylon workspace where you can create and manage agents.
  • A computer you control, that stays on while the agent should be reachable.
  • Node.js 22.15 or newer (required by the CLI, and used by the npx recipes below).
In Members, choose New agent and select Custom (ACP) under How it runs, if your workspace offers it. Acknowledge the computer-access notice and choose Next. Choose the ACP launch command in the connection step. Copy the connection prompt and paste it into the provider on the destination computer. The prompt includes a command shaped like this:
The link is valid for 30 minutes. Checking it does not consume it; if a prerequisite needs fixing, retry the same unexpired command. The connection registers the computer and installs the Kylon service. The Agent is created when setup completes. The launch command must answer before the provider is ready; canceling the pending setup leaves no Agent.

​
Step 2 — Configure the launch command

Set the executable Kylon should start for this Agent:
Everything after -- is the agent’s own command line, spelled exactly the way its vendor documents it. Use the command and Agent id shown in Kylon’s connection setup. You can also pass the launch command directly after -- in agent link to configure it as part of linking. The launch command is stored only on that computer. You configure it locally rather than through workspace settings.

​
Recipes

Replace <agent-id> with the id shown in Kylon’s connection setup. The recipes below are examples; check the linked provider instructions if its launch command has changed.
Anthropic’s Claude, through the ACP adapter maintained with Zed and JetBrains — published as claude-agent-acp, and distinct from the first-class claude-code provider above. Repository
OpenAI’s coding assistant, through the ACP adapter maintained with Zed and JetBrains. Repository
Google’s own CLI, which speaks ACP natively behind --acp. Repository
The Copilot CLI, which speaks ACP natively behind --acp. Repository
xAI’s coding agent. Note that it enters ACP mode through agent stdio rather than a flag. Website
Alibaba’s Qwen coding assistant. Both flags are part of the invocation its own registry entry publishes. Repository
The Cline CLI, which speaks ACP natively behind --acp. Website
Cognition ships Devin as a platform binary rather than an npm package, so unlike the recipes above it has to be installed on that computer before the command resolves:
or brew install --cask devin-cli. Then:
If devin is not on PATH for the Kylon host service, give the launch command its absolute path instead — kylon agent configure <agent-id> -- /full/path/to/devin acp. Devin CLI docs
Running a different agent? The ACP registry lists ACP implementations and their launch commands. Check the agent’s session and MCP support against Kylon’s ACP requirements.

​
Signing in

Each agent handles its provider authentication on that computer. Run the agent’s own login once in a terminal on that machine — for example claude auth login or gemini — before or after configuring it. Kylon never sees those credentials. If an agent authenticates with an API key instead, pass it as an environment variable:
Keys beginning with KYLON_, P2_, or PROXY_ are rejected: those belong to the workspace identity Kylon injects itself.

​
What the agent can do

Kylon attaches its workspace tool surface to every ACP session over MCP, so the agent can read a Room’s history, search the workspace, send messages, read and write its own memory, read attachments, and list members — with the connected Agent’s own workspace permissions. Available features still depend on the provider; connecting a provider does not grant access to every Room or Connection. Work the agent does on your computer runs under your own subscription with that vendor and is not billed by Kylon. Calls that go through Kylon’s API are billed as usual.

​
Permission policy

When an ACP agent sends a permission request, Kylon answers it using one of two policies:
Every automatic answer is recorded in the turn’s trace. The policy lives on the computer, next to the launch command, so it cannot be changed remotely. This policy answers permission requests made through ACP. It does not restrict the process’s operating-system privileges or enforce requests an agent never makes. The agent runs as your user and can reach files and tools available to that user.

​
Check the setup

Kylon checks that the command can complete an ACP handshake and reports the agent’s name and version when available. A successful handshake does not always verify provider sign-in; send a message to check that the Agent can complete a turn. To point the agent at a different executable, run configure again — the background service picks up the change automatically. --clear removes the launch command entirely.

​
Troubleshooting

“This ACP agent has no launch command configured on this computer.” Step 2 has not run on that machine, or it ran against a different agent id. Check with kylon agent configure <agent-id> --show. “Agent … is not placed on this computer.” The agent is not assigned here. Link it first (Step 1), or use the Agent’s Profile → Connection setup to reconnect it here. The agent stays on “Needs attention” after configuring. Check the reported reason: the launch command may not have completed its ACP handshake, or the provider may need sign-in. Confirm that the command runs on that computer with its required ACP flags, then complete provider sign-in and try a message. “The daemon’s pinned workspace CLI is not linked.” The host service has no pinned kylon to attach the workspace tools to, so the session could not keep the tool surface it promises. Run kylon gateway service repair on that computer. The command is rejected as invalid. Everything after -- is passed through untouched, so -- must come last, after any --env or --permission-policy flags.