#one agent multiple persistent ACP threads across different CLI platforms

10 messages · Page 1 of 1 (latest)

stable sapphire
#

Can a single OpenClaw agent maintain multiple persistent ACP threads across different ACP platforms at the same time, for example one persistent Claude thread, one persistent Codex thread, and one persistent Gemini thread?

More specifically:

• can all of these belong to the same OpenClaw

agent identity

• while each ACP thread keeps its own persistent state and continuity
• and without cross-thread context collision or session overwriting

If yes, what is the correct architecture or session model in OpenClaw for doing this cleanly? @obtuse bison

pearl prismBOT
flat nebulaBOT
#

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

pearl prismBOT
obtuse bisonBOT
#

Yes, with one important nuance:

Yes at the OpenClaw/bot level.
No, not as one shared ACP session.

Clean model:

  • One OpenClaw identity/persona can front everything
  • Many separate ACP sessions can run behind it at once
  • One persistent thread/topic/conversation = one ACP session key
  • Each Codex, Claude, Gemini thread keeps its own continuity
  • No collision, as long as you do not reuse the same session key across them

Recommended architecture

Best pattern:

  • keep your normal OpenClaw agent as the parent/orchestrator
#
  • spawn separate ACP sessions per harness/thread:
    • Codex thread -> its own ACP session
    • Claude thread -> its own ACP session
    • Gemini thread -> its own ACP session

Example spawn model:

{
  "runtime": "acp",
  "agentId": "codex",
  "thread": true,
  "mode": "session"
}

And separately:

#
{
  "runtime": "acp",
  "agentId": "claude",
  "thread": true,
  "mode": "session"
}

and:

{
  "runtime": "acp",
  "agentId": "gemini",
  "thread": true,
#
  "mode": "session"
}

What isolates them

OpenClaw gives each ACP spawn its own session key, shaped like:

agent:<target>:acp:<uuid>

That session key is the isolation boundary.
So the safe rule is:

Never point multiple harnesses/threads at the same ACP session key unless you intentionally want shared state.

#

"Same agent identity" answer

If by same identity you mean:

  • same bot
  • same OpenClaw deployment
  • same outward persona in chat

then yes.

If you mean:

  • literally one internal ACP session/store for Codex + Claude + Gemini

then no, that's the wrong model.

When to use which

#
  • Ad hoc persistent threads: use /acp spawn <harness> --mode persistent --thread auto
  • Fixed always-on channel/thread bindings: use top-level bindings[] with type: "acp"

Config bits to check

For Discord thread-bound ACP sessions, make sure you have at least:

  • acp.enabled = true
  • session.threadBindings.enabled = true
  • channels.discord.threadBindings.spawnAcpSessions = true

Also set acp.maxConcurrentSessions high enough for however many you want live.

One more gotcha

Do not confuse this with openclaw acp bridge mode. In bridge mode, multiple ACP clients sharing one Gateway session key are only best-effort isolated. For your use case, the right thing is separate ACP harness sessions, not shared bridge sessions.