#Multi-gateway

1 messages Β· Page 1 of 1 (latest)

slow osprey
quiet turtleBOT
viral furnaceBOT
#

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

quiet turtleBOT
forest cipherBOT
#

Short answer, not as a live in-place switch.

The rescue gateway is supposed to have its own profile, state dir, workspace, and ports, so it will not automatically inherit the current Discord-bound ACP binding from the main gateway. Docs: https://docs.openclaw.ai/gateway/multiple-gateways

What does work:

  • start the rescue gateway as its own isolated profile
  • on the current ACP session, grab the session id with /acp status
  • on the rescue gateway, spawn/bind a new ACP session there, optionally using resumeSessionId to continue the same upstream Codex/Claude session if that harness supports session/load
    Docs: https://docs.openclaw.ai/tools/acp-agents

So the pattern is:

  1. new gateway
  2. new OpenClaw binding
  3. optionally resume the old ACP runtime session
#

I would not have both gateways trying to own the same Discord conversation binding at once, that gets messy fast.

If you want, paste:

  • openclaw --version
  • whether both gateways are on the same host
  • which ACP agent you mean (Codex, Claude Code, Gemini, etc.)

and I can give you the exact safest steps.

If this fixed it, please right-click the solution message β†’ Apps β†’ βœ… Mark Solution so Answer Overflow can index it.