openclaw - 💡(How to fix) Fix voice-call: CLI `voicecall call` cannot run when gateway is owning the webhook port [1 comments, 2 participants]

Bug / Missing Feature

When the OpenClaw gateway daemon is running and the voice-call plugin is enabled, the gateway opens its own webhook listener (default 127.0.0.1:3334).

If you then run openclaw voicecall call ... from the CLI, it fails with:

[openclaw] Failed to start CLI: Error: listen EADDRINUSE: address already in use 127.0.0.1:3334
    at Server.setupListenHandle [as _listen2] (node:net:2008:16)
    ...

because the CLI also calls createVoiceCallRuntime() (in dist/runtime-entry-*.js), which unconditionally spins up its own VoiceCallWebhookServer on the same port.

Repro

1. Enable the bundled voice-call plugin and configure Twilio.
2. Set a publicUrl and run openclaw gateway start (or restart). Confirm the gateway logs:

   [voice-call] Webhook server listening on http://127.0.0.1:3334/voice/webhook
   [voice-call] Realtime voice provider: openai

3. From the same host, run:

   openclaw voicecall call --to "+1XXXXXXXXXX" --message "test"

4. Observe EADDRINUSE.

Expected

One of:

• The CLI detects an already-running gateway voice-call runtime and forwards the call request to it (e.g. via HTTP / RPC / Unix socket), rather than building a parallel runtime.
• A new --use-gateway / --remote / --gateway-url flag that explicitly delegates to the running gateway.
• At minimum, a clearer error message that says "Gateway is already running voice-call on port 3334. Use openclaw chat / agent tool / direct REST instead."

Workaround

Place the call directly via Twilio REST while pointing Url at the gateway's public webhook URL (https://<tailnet>.ts.net/voice/webhook) — works fine, but bypasses the CLI.

Environment

• OpenClaw 2026.4.24 (cbcfdf6)
• macOS 24.3.0 (arm64)
• Node v25.9.0
• Twilio provider, Tailscale Funnel for webhook exposure

Thanks for the great 4/24 release otherwise — realtime conversation through Twilio is working through the gateway path.