2025-12-09 17:51:05 +00:00
|
|
|
|
---
|
2025-12-14 00:52:37 +00:00
|
|
|
|
summary: "Remote access using SSH tunnels (Gateway WS) and tailnets"
|
2025-12-09 17:51:05 +00:00
|
|
|
|
read_when:
|
|
|
|
|
|
- Running or troubleshooting remote gateway setups
|
|
|
|
|
|
---
|
2025-12-14 00:49:34 +00:00
|
|
|
|
# Remote access (SSH, tunnels, and tailnets)
|
|
|
|
|
|
|
|
|
|
|
|
This repo supports “remote over SSH” by keeping a single Gateway (the master) running on a host (e.g., your Mac Studio) and connecting clients to it.
|
|
|
|
|
|
|
|
|
|
|
|
- For **operators (you / the macOS app)**: SSH tunneling is the universal fallback.
|
2026-01-10 14:51:21 -06:00
|
|
|
|
- For **nodes (iOS/Android and future devices)**: prefer the Gateway **Bridge** when on the same LAN/tailnet (see [Discovery](/gateway/discovery)).
|
2025-12-14 00:49:34 +00:00
|
|
|
|
|
|
|
|
|
|
## The core idea
|
|
|
|
|
|
|
2026-01-03 11:46:58 +01:00
|
|
|
|
- The Gateway WebSocket binds to **loopback** on your configured port (defaults to 18789).
|
2025-12-14 00:49:34 +00:00
|
|
|
|
- For remote use, you forward that loopback port over SSH (or use a tailnet/VPN and tunnel less).
|
|
|
|
|
|
|
2026-01-11 03:17:06 +01:00
|
|
|
|
## Command flow (what runs where)
|
|
|
|
|
|
|
|
|
|
|
|
One gateway daemon owns state + providers. Nodes are peripherals.
|
|
|
|
|
|
|
|
|
|
|
|
Flow example (Telegram → node):
|
|
|
|
|
|
- Telegram message arrives at the **Gateway**.
|
|
|
|
|
|
- Gateway runs the **agent** and decides whether to call a node tool.
|
|
|
|
|
|
- Gateway calls the **node** over the Bridge (`node.*` RPC).
|
|
|
|
|
|
- Node returns the result; Gateway replies back out to Telegram.
|
|
|
|
|
|
|
|
|
|
|
|
Notes:
|
|
|
|
|
|
- **Nodes do not run the gateway daemon.** Only one gateway should run per host.
|
|
|
|
|
|
- macOS app “node mode” is just a node client over the Bridge.
|
|
|
|
|
|
|
2025-12-14 00:49:34 +00:00
|
|
|
|
## SSH tunnel (CLI + tools)
|
|
|
|
|
|
|
|
|
|
|
|
Create a local tunnel to the remote Gateway WS:
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
ssh -N -L 18789:127.0.0.1:18789 user@host
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
With the tunnel up:
|
2026-01-04 14:32:47 +00:00
|
|
|
|
- `clawdbot health` and `clawdbot status --deep` now reach the remote gateway via `ws://127.0.0.1:18789`.
|
|
|
|
|
|
- `clawdbot gateway {status,health,send,agent,call}` can also target the forwarded URL via `--url` when needed.
|
2025-12-14 00:49:34 +00:00
|
|
|
|
|
2026-01-04 14:32:47 +00:00
|
|
|
|
Note: replace `18789` with your configured `gateway.port` (or `--port`/`CLAWDBOT_GATEWAY_PORT`).
|
2026-01-03 11:46:58 +01:00
|
|
|
|
|
2026-01-01 20:10:50 +01:00
|
|
|
|
## CLI remote defaults
|
|
|
|
|
|
|
|
|
|
|
|
You can persist a remote target so CLI commands use it by default:
|
|
|
|
|
|
|
|
|
|
|
|
```json5
|
|
|
|
|
|
{
|
|
|
|
|
|
gateway: {
|
|
|
|
|
|
mode: "remote",
|
|
|
|
|
|
remote: {
|
|
|
|
|
|
url: "ws://127.0.0.1:18789",
|
|
|
|
|
|
token: "your-token"
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
When the gateway is loopback-only, keep the URL at `ws://127.0.0.1:18789` and open the SSH tunnel first.
|
|
|
|
|
|
|
2025-12-17 23:05:28 +01:00
|
|
|
|
## Chat UI over SSH
|
2025-12-14 00:49:34 +00:00
|
|
|
|
|
2025-12-17 23:05:28 +01:00
|
|
|
|
WebChat no longer uses a separate HTTP port. The SwiftUI chat UI connects directly to the Gateway WebSocket.
|
2025-12-14 00:49:34 +00:00
|
|
|
|
|
2025-12-17 23:05:28 +01:00
|
|
|
|
- Forward `18789` over SSH (see above), then connect clients to `ws://127.0.0.1:18789`.
|
|
|
|
|
|
- On macOS, prefer the app’s “Remote over SSH” mode, which manages the tunnel automatically.
|
2025-12-14 00:49:34 +00:00
|
|
|
|
|
|
|
|
|
|
## macOS app “Remote over SSH”
|
|
|
|
|
|
|
|
|
|
|
|
The macOS menu bar app can drive the same setup end-to-end (remote status checks, WebChat, and Voice Wake forwarding).
|
|
|
|
|
|
|
2026-01-10 14:51:21 -06:00
|
|
|
|
Runbook: [macOS remote access](/platforms/mac/remote).
|