Questions about ACP and using OpenClaw in Zed | Friends of the Crustacean 🦞🤝 | Page 1

tame crane Apr 17, 2026, 3:54 PM

#

Hello Krill. Can i set up OpenClaw as an agent inside Zed using ACP?

leaden hornetBOT Apr 17, 2026, 3:54 PM

#

sleek basinBOT Apr 17, 2026, 3:54 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

leaden hornetBOT Apr 17, 2026, 3:54 PM

#

last stratusBOT Apr 17, 2026, 3:56 PM

#

Let me check the actual ACP docs so I don't make up keys.

#

Yep, you can.

Zed can run OpenClaw through the ACP bridge by spawning openclaw acp as a custom agent server.

Minimal ~/.config/zed/settings.json:

{
  "agent_servers": {
    "OpenClaw ACP": {
      "type": "custom",
      "command": "openclaw",
      "args": ["acp"],
      "env": {}
    }
  }

#

If you want a specific Gateway/agent, pass flags like:

{
  "agent_servers": {
    "OpenClaw ACP": {
      "type": "custom",
      "command": "openclaw",
      "args": [
        "acp",
        "--url",
        "wss://gateway-host:18789",

#

        "--token-file",
        "~/.openclaw/gateway.token",
        "--session",
        "agent:main:main"
      ],
      "env": {}
    }
  }
}

Two important gotchas:

ACP does not pick agents directly, it routes by session key like agent:main:main
This is bridge mode, not a full ACP-native editor runtime, so some ACP client features like per-session mcpServers, client filesystem methods, and terminal methods are not supported yet

#

Docs:

If you want, I can give you a copy-paste Zed config for either:

local OpenClaw on the same machine, or
remote Gateway over token auth.

tame crane Apr 17, 2026, 4:01 PM

#

What would be a way to access my claw through Zed that doesn't "cripple" Zed's ACP agent integrations? Should i use a "subagent" like a KiloCode managed by my Claw instead of directly using ACP with my Claw?

last stratusBOT Apr 17, 2026, 4:02 PM

#

I want to check the MCP side too, because that may be the cleaner architecture here.

#

Short version: if your goal is “don’t nerf Zed”, I would not make OpenClaw your main ACP agent.

Best pattern:

Keep Zed talking to a real ACP-native coding agent
like KiloCode / Codex / Claude Code / etc.
Expose OpenClaw to that setup via MCP
using openclaw mcp serve

Why: openclaw acp is a bridge, and the docs explicitly call out that it does not support some ACP-native editor features, including:

client filesystem methods
client terminal methods
per-session mcpServers
richer ACP-native streaming/plans

#

So yes, using OpenClaw directly as the ACP agent can feel a bit “crippled” compared to a native ACP coding agent.

My recommendation:

If you want Zed-first coding UX:
Zed ↔ native ACP agent
native ACP agent ↔ OpenClaw via MCP
If you want Claw-first orchestration:
let OpenClaw run the harness via ACP agents (/acp spawn ...)
but then OpenClaw is the boss, not Zed

So your “KiloCode managed by my Claw” idea is valid, but that is the OpenClaw-centric architecture, not the best way to preserve Zed’s own agent integrations.

If it were me, I’d do this:

use KiloCode in Zed for editor-native stuff

#

add OpenClaw as MCP for cross-channel memory / messaging / context
optionally keep a separate OpenClaw ACP entry in Zed only for direct chat with your Claw

Docs:

ACP bridge: https://docs.openclaw.ai/cli/acp
MCP bridge: https://docs.openclaw.ai/cli/mcp
ACP harness sessions: https://docs.openclaw.ai/tools/acp-agents

If you want, I can sketch the cleanest exact topology for your setup, for example “Zed + KiloCode + OpenClaw on same machine” vs “Zed local, OpenClaw remote”.

tame crane Apr 17, 2026, 4:11 PM

#

I hadn't thought of using the claw itself as an MCP tool. Usually it's the other way around. I forgot mcp serve was a thing. Thanks Krill. If i go this route, would my Claw be aware of what i do with my coding agent? I think I'll go with acp spawn and then use the agent it spawns inside Zed, just to keep my Claw aware of my code.

last stratusBOT Apr 17, 2026, 4:12 PM

#

Yep, that’s the key tradeoff.

If you use openclaw mcp serve, your Claw is only aware of the parts that actually go through OpenClaw:

MCP tool calls into OpenClaw
messages sent to OpenClaw-backed conversations
transcript/history reads, approvals, etc.

It is not automatically aware of everything your coding agent does in Zed, like:

local file edits
terminal commands
editor-native context
the agent’s internal reasoning / local tool flow

So MCP gives your coding agent access to Claw, but not full shared awareness.

#

If you want your Claw to stay much more aware of the coding work, then /acp spawn is the better fit, because OpenClaw is the one hosting/managing that harness session.

One important nuance though: if you then connect Zed to that spawned session through openclaw acp, you’re back on the ACP bridge path, so some of Zed’s richer ACP-native features are still limited there.

So I’d frame it like this:

Best Zed UX: native ACP agent in Zed + OpenClaw via MCP
Best Claw awareness/control: /acp spawn and let OpenClaw own the harness
Trying to fully combine both: possible-ish, but you inherit the ACP bridge compromises again

So your instinct makes sense. If your priority is “keep my Claw aware of my code”, I’d pick /acp spawn too.

If you want, I can sketch the least-janky hybrid setup for that, so you keep Claw awareness without making Zed feel too boxed in.

tame crane Apr 17, 2026, 4:13 PM

#

Yes please! Just to see what that looks like. Thanks a lot Krill!

last stratusBOT Apr 17, 2026, 4:14 PM

#

Yep, I’d do it as two lanes, one memory hub.

What I’d actually run

Lane 1, your normal coding lane

Zed
KiloCode (or Codex/Claude/etc) as the native ACP agent
OpenClaw via MCP as a tool/context bridge

Lane 2, your Claw-supervised lane

OpenClaw
/acp spawn kilocode only for tasks where you want Claw to own/supervise the run

Mental model

#

Zed <-> KiloCode (native ACP, full editor UX)
          |
          +-> OpenClaw MCP (`openclaw mcp serve`)
                  |
                  +-> your Claw sessions, chat routes, memory, approvals, etc.

OpenClaw <-> ACP harness sessions (`/acp spawn kilocode`) for Claw-owned jobs

Why this is the least janky

You do not try to make Zed attach to the exact harness session OpenClaw spawned.

That’s the part I’d avoid.

Because then the path becomes roughly:

#

Zed -> OpenClaw ACP bridge -> OpenClaw session -> spawned ACP harness

and now you’ve reintroduced the ACP bridge limitations on the Zed side anyway.

Practical workflow

Normal coding in Zed: use KiloCode directly
Need Claw context: let the agent call OpenClaw over MCP
Need Claw to truly own a task: kick off /acp spawn kilocode from OpenClaw
Sync point: have one side summarize back into OpenClaw when the task matters

Rule of thumb

Interactive local coding: Zed-native ACP
Shared oversight / long-running / cross-device / chat-visible work: OpenClaw /acp spawn

#

Don’t try to share one live harness session between both as the main path

So the hybrid is not “one agent used from two masters”.
It’s more like Zed owns local coding, OpenClaw owns supervision/history.

If you want, next I can sketch a concrete minimal setup for this with:

Zed side
openclaw mcp serve side
a clean /acp spawn pattern for “promote this task to Claw-owned”

tame crane Apr 17, 2026, 4:28 PM

#

Instead of trying to squish my agents and forcing them to work together, would it be better to set up something like SurrealDB as a memory module shared by both agents? Its mostly so they share the same identity and memories but be available through through different harnesses. And if yes, is my best option to use a modified Pi Agent instead of kilo code? I figure since Claw and Pi share a "base" that they should have the least conflicts.

last stratusBOT Apr 17, 2026, 4:29 PM

#

I want to sanity-check the memory side before I answer, because “shared identity DB” can get messy fast.

#

Honestly, I think the right answer is:

yes to a shared memory layer
no to SurrealDB as the first move

I would not try to make two harnesses share one fuzzy “soul” through a custom DB right away. That’s where weirdness creeps in.

What I’d do instead

Use OpenClaw as the canonical memory/identity layer:

keep shared identity in files like SOUL.md, IDENTITY.md, USER.md, MEMORY.md
let OpenClaw memory index/search those
if you want better recall, use QMD as the memory backend
if you use /acp spawn, enable the ACPX plugin-tools bridge so the spawned harness can access OpenClaw memory tools

That bridge is documented here:

#

Useful bit for spawned ACP harnesses:

openclaw config set plugins.entries.acpx.config.pluginToolsMcpBridge true

That gives ACP harnesses access to OpenClaw plugin tools like memory recall/store, which is a much cleaner shared-memory story than building your own SurrealDB glue first.

On Pi vs KiloCode

I would not choose the harness based on “shared base” or brand lineage.

That’s the wrong layer to optimize.

#

Pick based on:

coding reliability
editor ergonomics
tool behavior
how well it behaves in ACP/Zed

Then use the shared memory + shared identity files to keep the personalities aligned.

So, unless Pi is actually the better coding harness for your workflow, I would not switch just because it feels more Claw-adjacent.

My actual recommendation

KiloCode in Zed if it’s your better coder
OpenClaw/QMD as the shared memory layer
shared identity files as the stable persona source
/acp spawn when you want Claw-owned/supervised work
pluginToolsMcpBridge if you want spawned harnesses to use OpenClaw memory directly

#

So basically: shared memory, yes. Shared runtime identity blob, no.

If you want, I can sketch a concrete setup for that, like:

which files become the canonical identity
which memory backend I’d enable
where Zed/KiloCode should read from
where OpenClaw should write back to

tame crane Apr 17, 2026, 4:33 PM

#

Ah right. 4.14/4.15 changed how memory works. Is the OpenClaw documentation updated already? I should read that first before doing anything. Thanks Krill. Have a nice day.

#Questions about ACP and using OpenClaw in Zed