Calling

Check calling availability with wx calls status, then use the CLI, OpenClaw or the control and media APIs. The current backend handles direct voice calls; video and conference capabilities remain off. Call metadata separates kind (direct/conference) from callType (voice/video).

Check availability

In a source build, run wx calls --help. The parent command only prints help; it does not connect, log in or open audio devices.
Run wx calls status against your selected daemon. Normal startup includes the native call backend. Accounts without a current authenticated session report empty capabilities: {}.
Require the corresponding capability before participating. An API route or a configured plugin does not make a call available.

Normal source and release builds include calling and local audio support; Build from source lists the prerequisites. A headless daemon does not open a microphone or speaker. Runtime account permissions and advertised capabilities determine whether a client may participate.

API connections

Use the Calls API reference for routes, complete command/event payloads, incoming-call examples and ownership rules. The separate media reference specifies attachment, JSON stream setup and raw PCM chunks.

A control connection observes calls without answering them. The first successful answer owns an incoming call; an outgoing call belongs to its initiator. Other authorized clients see same-account call metadata, including callType: "voice", but receive no audio and cannot start another call while busy. All call routes require the calls token scope and authorization headers.

Keep control connected through termination. Reconnecting does not reclaim ownership. An accepted end command starts cleanup, so wait for ended. An uncertain outcome needs inspection before another call.

The server checks connection heartbeat and call activity. Outgoing pickup and fresh authenticated peer-packet timeouts are both one minute. See the API reference for connection timeouts and media rules.

CLI and OpenClaw

Command	Behavior
`wx calls devices`	List local microphone/speaker IDs without connecting to a daemon or starting audio
`wx calls monitor --json`	Observe events without opening audio devices
`wx calls monitor`	Show “Waiting for calls. Ctrl-C exits.” until a call comes in. Open audio on acceptance.
`wx calls dial CONTACT`	Participate using this computer’s microphone and speakers
`wx calls answer [CALL_ID]`	Answer the current matching offer using local audio

Release executables include local audio support. The monitor shows the incoming prompt after the daemon acknowledges ringing. Accepting stays tied to the selected call, even if another call arrives later.

Run wx calls devices first, then select endpoints with wx calls dial CONTACT --input-device INPUT_ID --output-device OUTPUT_ID. Without those options, the OS defaults are used. Linux accepts PulseAudio or PipeWire-Pulse names; Windows accepts endpoint IDs. On macOS, select the defaults in System Settings; custom endpoint IDs are not supported by the current adapter.

Interactive calls show the keyboard controls above the audio meters.

m + Enter  Mute/unmute    h + Enter  Hang up
Ctrl-C     End call       ? + Enter  Show keys
Mic [#######...] -18dB  Speaker [########..] -10dB
>

The bars rise with louder audio and fall toward silence. 0 dB is digital full scale; ! marks a recent peak near clipping. A muted microphone shows no outgoing signal. The speaker meter measures audio sent to playback, not the hardware volume setting or sound in the room. Meters stay out of JSON, redirected output and terminals too narrow to show both levels on one line.

Run WX_CALL_DEBUG=1 wx calls monitor to print a timestamped trace to stderr while using the call controls. It shows incoming call events with the media owner token removed, whether the first audio frame was written to the socket, and any WebSocket close code or reason the CLI received.

Configure independent voice/video permissions, realtime speech models, OpenAI credentials and consultation in Set up calling.