Knoten

Ein Node ist ein Begleitgerät (macOS/iOS/Android/ohne grafische Oberfläche), das sich mit dem Gateway-WebSocket verbindet (derselbe Port wie für Operatoren), mit role: "node" angemeldet ist und über node.invoke eine Befehlsschnittstelle bereitstellt (z. B. canvas.*, camera.*, device.*, notifications.*, system.*). Protokolldetails: Gateway-Protokoll.

Legacy-Transport: Bridge-Protokoll (TCP JSONL; nur historisch für aktuelle Nodes).

macOS kann auch im Node-Modus laufen: Die Menüleisten-App verbindet sich mit dem WS-Server des Gateways und stellt ihre lokalen Canvas-/Kamera-Befehle als Node bereit (sodass openclaw nodes … gegen diesen Mac funktioniert). Im Remote-Gateway-Modus wird Browser-Automatisierung vom CLI-Node-Host (openclaw node run oder der installierte Node-Dienst) verarbeitet, nicht vom nativen App-Node.

Hinweise:

• Nodes sind Peripheriegeräte, keine Gateways. Sie führen den Gateway-Dienst nicht aus.
• Telegram-/WhatsApp-/usw.-Nachrichten landen auf dem Gateway, nicht auf Nodes.
• Troubleshooting-Runbook: /nodes/troubleshooting

Kopplung + Status

WS-Nodes verwenden Gerätekopplung. Nodes legen während connect eine Geräteidentität vor; das Gateway erstellt eine Gerätekopplungsanfrage für role: node. Genehmigen Sie sie über die Geräte-CLI (oder UI).

Schnellstart per CLI:

openclaw devices listopenclaw devices approve <requestId>openclaw devices reject <requestId>openclaw nodes statusopenclaw nodes describe --node <idOrNameOrIp>

Wenn ein Node es mit geänderten Auth-Details erneut versucht (Rolle/Scopes/öffentlicher Schlüssel), wird die vorherige ausstehende Anfrage ersetzt und eine neue requestId erstellt. Führen Sie vor der Genehmigung erneut openclaw devices list aus.

Hinweise:

• nodes status markiert einen Node als gekoppelt, wenn seine Gerätekopplungsrolle node enthält.
• Der Gerätekopplungseintrag ist der dauerhafte Vertrag für genehmigte Rollen. Token- Rotation bleibt innerhalb dieses Vertrags; sie kann einen gekoppelten Node nicht auf eine andere Rolle hochstufen, die durch die Kopplungsgenehmigung nie gewährt wurde.
• node.pair.* (CLI: openclaw nodes pending/approve/reject/remove/rename) ist ein separater, vom Gateway verwalteter Node-Kopplungsspeicher; er schützt den WS-connect-Handshake nicht.
• openclaw nodes remove --node <id|name|ip> entfernt eine Node-Kopplung. Bei einem gerätegestützten Node entzieht es die node-Rolle des Geräts in devices/paired.json und trennt die Node-Rollen-Sitzungen dieses Geräts — ein Gerät mit mehreren Rollen behält seine Zeile und verliert nur die node-Rolle, während eine reine Node-Gerätezeile gelöscht wird. Außerdem wird jeder passende Eintrag aus dem separaten, vom Gateway verwalteten Node- Kopplungsspeicher entfernt. operator.pairing darf Nicht-Operator-Node-Zeilen entfernen; ein Device-Token-Aufrufer, der seine eigene Node-Rolle auf einem Gerät mit mehreren Rollen widerruft, benötigt zusätzlich operator.admin.
• Der Genehmigungsumfang folgt den deklarierten Befehlen der ausstehenden Anfrage:
  • Anfrage ohne Befehle: operator.pairing
  • Nicht-Exec-Node-Befehle: operator.pairing + operator.write
  • system.run / system.run.prepare / system.which: operator.pairing + operator.admin

Remote-Node-Host (system.run)

Verwenden Sie einen Node-Host, wenn Ihr Gateway auf einer Maschine läuft und Sie Befehle auf einer anderen ausführen möchten. Das Modell spricht weiterhin mit dem Gateway; das Gateway leitet exec-Aufrufe an den Node-Host weiter, wenn host=node ausgewählt ist.

Was wo läuft

• Gateway-Host: empfängt Nachrichten, führt das Modell aus, routet Tool-Aufrufe.
• Node-Host: führt system.run/system.which auf der Node-Maschine aus.
• Genehmigungen: werden auf dem Node-Host über ~/.openclaw/exec-approvals.json erzwungen.

Hinweis zu Genehmigungen:

• Genehmigungsbasierte Node-Ausführungen binden den exakten Anfragekontext.
• Für direkte Shell-/Runtime-Dateiausführungen bindet OpenClaw nach bestem Aufwand außerdem einen konkreten lokalen Dateioperanden und verweigert die Ausführung, wenn sich diese Datei vor der Ausführung ändert.
• Wenn OpenClaw für einen Interpreter-/Runtime-Befehl nicht genau eine konkrete lokale Datei identifizieren kann, wird die genehmigungsbasierte Ausführung verweigert, statt vollständige Runtime-Abdeckung vorzutäuschen. Verwenden Sie Sandboxing, separate Hosts oder eine explizit vertrauenswürdige Allowlist bzw. einen vollständigen Workflow für umfassendere Interpreter-Semantik.

Node-Host starten (Vordergrund)

Auf der Node-Maschine:

openclaw node run --host <gateway-host> --port 18789 --display-name "Build Node"

Remote-Gateway über SSH-Tunnel (Loopback-Bindung)

Wenn das Gateway an Loopback gebunden ist (gateway.bind=loopback, Standard im lokalen Modus), können sich Remote-Node-Hosts nicht direkt verbinden. Erstellen Sie einen SSH-Tunnel und richten Sie den Node-Host auf das lokale Ende des Tunnels.

Beispiel (Node-Host -> Gateway-Host):

# Terminal A (keep running): forward local 18790 -> gateway 127.0.0.1:18789ssh -N -L 18790:127.0.0.1:18789 user@gateway-host # Terminal B: export the gateway token and connect through the tunnelexport OPENCLAW_GATEWAY_TOKEN="<gateway-token>"openclaw node run --host 127.0.0.1 --port 18790 --display-name "Build Node"

Hinweise:

• openclaw node run unterstützt Authentifizierung per Token oder Passwort.
• Env-Vars werden bevorzugt: OPENCLAW_GATEWAY_TOKEN / OPENCLAW_GATEWAY_PASSWORD.
• Config-Fallback ist gateway.auth.token / gateway.auth.password.
• Im lokalen Modus ignoriert der Node-Host absichtlich gateway.remote.token / gateway.remote.password.
• Im Remote-Modus kommen gateway.remote.token / gateway.remote.password gemäß den Remote-Prioritätsregeln infrage.
• Wenn aktive lokale gateway.auth.* SecretRefs konfiguriert, aber nicht aufgelöst sind, schlägt die Node-Host-Authentifizierung geschlossen fehl.
• Die Authentifizierungsauflösung des Node-Hosts berücksichtigt nur OPENCLAW_GATEWAY_*-Env-Vars.

Node-Host starten (Dienst)

openclaw node install --host <gateway-host> --port 18789 --display-name "Build Node"openclaw node startopenclaw node restart

Koppeln + benennen

Auf dem Gateway-Host:

openclaw devices listopenclaw devices approve <requestId>openclaw nodes status

Wenn der Node es mit geänderten Auth-Details erneut versucht, führen Sie openclaw devices list erneut aus und genehmigen Sie die aktuelle requestId.

Benennungsoptionen:

• --display-name bei openclaw node run / openclaw node install (wird auf dem Node in ~/.openclaw/node.json persistiert).
• openclaw nodes rename --node <id|name|ip> --name "Build Node" (Gateway-Überschreibung).

Befehle auf die Allowlist setzen

Exec-Genehmigungen gelten pro Node-Host. Fügen Sie Allowlist-Einträge vom Gateway aus hinzu:

openclaw approvals allowlist add --node <id|name|ip> "/usr/bin/uname"openclaw approvals allowlist add --node <id|name|ip> "/usr/bin/sw_vers"

Genehmigungen liegen auf dem Node-Host unter ~/.openclaw/exec-approvals.json.

Exec auf den Node ausrichten

Standardwerte konfigurieren (Gateway-Config):

openclaw config set tools.exec.host nodeopenclaw config set tools.exec.security allowlistopenclaw config set tools.exec.node "<id-or-name>"

Oder pro Sitzung:

/exec host=node security=allowlist node=<id-or-name>

Sobald dies gesetzt ist, läuft jeder exec-Aufruf mit host=node auf dem Node-Host (vorbehaltlich der Node-Allowlist/Genehmigungen).

host=auto wählt den Node nicht implizit selbst aus, aber eine explizite Anfrage pro Aufruf mit host=node ist von auto aus erlaubt. Wenn Node-Exec der Standard für die Sitzung sein soll, setzen Sie ausdrücklich tools.exec.host=node oder /exec host=node ....

Verwandt:

• Node-Host-CLI
• Exec-Tool
• Exec-Genehmigungen

Lokale Modellinferenz

Ein Desktop- oder Server-Node kann chatfähige Modelle von einem Ollama-Server bereitstellen, der auf diesem Node läuft. Agenten verwenden das node_inference-Tool des Ollama-Plugins, um installierte Modelle zu ermitteln und einen begrenzten Prompt remote auszuführen; das Gateway benötigt keinen direkten Netzwerkzugriff auf Ollama. Siehe Node-lokale Ollama-Inferenz für Einrichtung, Modellfilterung und direkte Verifizierungsbefehle.

Befehle aufrufen

Low-Level (rohes RPC):

openclaw nodes invoke --node <idOrNameOrIp> --command canvas.eval --params '{"javaScript":"location.href"}'

Für die gängigen Workflows „dem Agenten einen MEDIA-Anhang geben“ gibt es Higher-Level-Helfer.

Befehlsrichtlinie

Node-Befehle müssen zwei Prüfungen bestehen, bevor sie aufgerufen werden können:

1. Der Node muss den Befehl in seiner WebSocket-connect.commands-Liste deklarieren.
2. Die Plattformrichtlinie des Gateways muss den deklarierten Befehl zulassen.

Windows- und macOS-Begleit-Nodes erlauben standardmäßig sichere deklarierte Befehle wie canvas.*, camera.list, location.get und screen.snapshot. Vertrauenswürdige Nodes, die die talk-Fähigkeit ankündigen oder talk.*-Befehle deklarieren, erlauben standardmäßig auch deklarierte Push-to-Talk-Befehle (talk.ptt.start, talk.ptt.stop, talk.ptt.cancel, talk.ptt.once), unabhängig vom Plattformlabel. Gefährliche oder datenschutzintensive Befehle wie camera.snap, camera.clip und screen.record erfordern weiterhin ein explizites Opt-in mit gateway.nodes.allowCommands. gateway.nodes.denyCommands hat immer Vorrang vor Standardwerten und zusätzlichen Allowlist-Einträgen.

Plugin-eigene Node-Befehle können eine Gateway-Node-Invoke-Richtlinie hinzufügen. Diese Richtlinie läuft nach der Allowlist-Prüfung und vor der Weiterleitung an den Node, sodass rohes node.invoke, CLI-Helfer und dedizierte Agenten-Tools dieselbe Plugin- Berechtigungsgrenze teilen. Gefährliche Plugin-Node-Befehle erfordern weiterhin ein explizites Opt-in über gateway.nodes.allowCommands.

Nachdem ein Node seine deklarierte Befehlsliste geändert hat, lehnen Sie die alte Gerätekopplung ab und genehmigen Sie die neue Anfrage, damit das Gateway den aktualisierten Befehls-Snapshot speichert.

Config (openclaw.json)

Node-bezogene Einstellungen befinden sich unter gateway.nodes und tools.exec:

{  gateway: {    nodes: {      // Auto-approve first-time node pairing from trusted networks (CIDR list).      // Disabled when unset. Only applies to first-time role:node requests      // with no requested scopes; does not auto-approve upgrades.      pairing: {        autoApproveCidrs: ["192.168.1.0/24"],      },      // Opt into dangerous/privacy-heavy node commands (camera.snap, etc.).      allowCommands: ["camera.snap", "screen.record"],      // Block exact command names even if defaults or allowCommands include them.      denyCommands: ["camera.clip"],    },  },  tools: {    exec: {      // Default exec host: "node" routes all exec calls to a paired node.      host: "node",      // Security mode for node exec: allow only approved/allowlisted commands.      security: "allowlist",      // Pin exec to a specific node (id or name). Omit to allow any node.      node: "build-node",    },  },}

Verwenden Sie exakte Node-Befehlsnamen. denyCommands entfernt einen Befehl auch dann, wenn ein Plattformstandard oder allowCommands-Eintrag ihn andernfalls zulassen würde. Siehe Gateway-Konfigurationsreferenz für Felddetails zur Gateway-Node-Kopplung und Befehlsrichtlinie.

Exec-Node-Überschreibung pro Agent:

{  agents: {    list: [      {        id: "main",        tools: { exec: { node: "build-node" } },      },    ],  },}

Screenshots (Canvas-Snapshots)

Wenn der Node das Canvas (WebView) anzeigt, gibt canvas.snapshot { format, base64 } zurück.

CLI-Helfer (schreibt in eine temporäre Datei und gibt den gespeicherten Pfad aus):

openclaw nodes canvas snapshot --node <idOrNameOrIp> --format pngopenclaw nodes canvas snapshot --node <idOrNameOrIp> --format jpg --max-width 1200 --quality 0.9

Canvas-Steuerungen

openclaw nodes canvas present --node <idOrNameOrIp> --target https://example.comopenclaw nodes canvas hide --node <idOrNameOrIp>openclaw nodes canvas navigate https://example.com --node <idOrNameOrIp>openclaw nodes canvas eval --node <idOrNameOrIp> --js "document.title"

Hinweise:

• canvas present akzeptiert URLs oder lokale Dateipfade (--target) sowie optional --x/--y/--width/--height zur Positionierung.
• canvas eval akzeptiert Inline-JS (--js) oder ein Positionsargument.

A2UI (Canvas)

openclaw nodes canvas a2ui push --node <idOrNameOrIp> --text "Hello"openclaw nodes canvas a2ui push --node <idOrNameOrIp> --jsonl ./payload.jsonlopenclaw nodes canvas a2ui reset --node <idOrNameOrIp>

Hinweise:

• Mobile Knoten verwenden eine gebündelte, App-eigene A2UI-Seite für aktionsfähiges Rendering.
• Es wird nur A2UI v0.8 JSONL unterstützt (v0.9/createSurface wird abgelehnt).
• iOS und Android rendern entfernte Gateway Canvas-Seiten, aber A2UI-Schaltflächenaktionen werden nur von der gebündelten, App-eigenen A2UI-Seite ausgelöst. Gateway-gehostete HTTP/HTTPS-A2UI-Seiten sind auf diesen mobilen Clients nur zur Darstellung vorgesehen.

Fotos + Videos (Knotenkamera)

Fotos (jpg):

openclaw nodes camera list --node <idOrNameOrIp>openclaw nodes camera snap --node <idOrNameOrIp>            # default: both facings (2 MEDIA lines)openclaw nodes camera snap --node <idOrNameOrIp> --facing front

Videoclips (mp4):

openclaw nodes camera clip --node <idOrNameOrIp> --duration 10sopenclaw nodes camera clip --node <idOrNameOrIp> --duration 3000 --no-audio

Hinweise:

• Der Knoten muss für canvas.* und camera.* im Vordergrund sein (Hintergrundaufrufe geben NODE_BACKGROUND_UNAVAILABLE zurück).
• Die Clipdauer wird begrenzt (derzeit <= 60s), um übergroße base64-Nutzlasten zu vermeiden.
• Android fragt nach Möglichkeit nach CAMERA-/RECORD_AUDIO-Berechtigungen; verweigerte Berechtigungen schlagen mit *_PERMISSION_REQUIRED fehl.

Bildschirmaufzeichnungen (Knoten)

Unterstützte Knoten stellen screen.record (mp4) bereit. Beispiel:

openclaw nodes screen record --node <idOrNameOrIp> --duration 10s --fps 10openclaw nodes screen record --node <idOrNameOrIp> --duration 10s --fps 10 --no-audio

Hinweise:

• Die Verfügbarkeit von screen.record hängt von der Knotenplattform ab.
• Bildschirmaufzeichnungen werden auf <= 60s begrenzt.
• --no-audio deaktiviert die Mikrofonaufnahme auf unterstützten Plattformen.
• Verwenden Sie --screen <index>, um eine Anzeige auszuwählen, wenn mehrere Bildschirme verfügbar sind.

Standort (Knoten)

Knoten stellen location.get bereit, wenn Standort in den Einstellungen aktiviert ist.

CLI-Helfer:

openclaw nodes location get --node <idOrNameOrIp>openclaw nodes location get --node <idOrNameOrIp> --accuracy precise --max-age 15000 --location-timeout 10000

Hinweise:

• Standort ist standardmäßig deaktiviert.
• „Immer“ erfordert eine Systemberechtigung; Abrufe im Hintergrund erfolgen nach bestem Aufwand.
• Die Antwort enthält Breiten-/Längengrad, Genauigkeit (Meter) und Zeitstempel.

SMS (Android-Knoten)

Android-Knoten können sms.send bereitstellen, wenn der Benutzer die SMS-Berechtigung erteilt und das Gerät Telefonie unterstützt.

Low-Level-Aufruf:

openclaw nodes invoke --node <idOrNameOrIp> --command sms.send --params '{"to":"+15555550123","message":"Hello from OpenClaw"}'

Hinweise:

• Die Berechtigungsaufforderung muss auf dem Android-Gerät akzeptiert werden, bevor die Fähigkeit angekündigt wird.
• Geräte ohne Telefonie, die nur Wi-Fi unterstützen, kündigen sms.send nicht an.

Android-Geräte- + persönliche Datenbefehle

Android-Knoten können zusätzliche Befehlsfamilien ankündigen, wenn die entsprechenden Fähigkeiten aktiviert sind.

Verfügbare Familien:

• device.status, device.info, device.permissions, device.health
• device.apps, wenn die Freigabe installierter Apps in den Android-Einstellungen aktiviert ist
• notifications.list, notifications.actions
• photos.latest
• contacts.search, contacts.add
• calendar.events, calendar.add
• callLog.search
• sms.search
• motion.activity, motion.pedometer

Beispielaufrufe:

openclaw nodes invoke --node <idOrNameOrIp> --command device.status --params '{}'openclaw nodes invoke --node <idOrNameOrIp> --command device.apps --params '{"limit":10}'openclaw nodes invoke --node <idOrNameOrIp> --command notifications.list --params '{}'openclaw nodes invoke --node <idOrNameOrIp> --command photos.latest --params '{"limit":1}'

Hinweise:

• device.apps ist Opt-in und gibt standardmäßig im Launcher sichtbare Apps zurück.
• Motion-Befehle sind durch verfügbare Sensoren fähigkeitsgesteuert.

Systembefehle (Knotenhost / Mac-Knoten)

Der macOS-Knoten stellt system.run, system.notify und system.execApprovals.get/set bereit. Der Headless-Knotenhost stellt system.run, system.which und system.execApprovals.get/set bereit.

Beispiele:

openclaw nodes notify --node <idOrNameOrIp> --title "Ping" --body "Gateway ready"openclaw nodes invoke --node <idOrNameOrIp> --command system.which --params '{"name":"git"}'

Hinweise:

• system.run gibt stdout/stderr/Exit-Code in der Nutzlast zurück.
• Shell-Ausführung läuft jetzt über das exec-Tool mit host=node; nodes bleibt die direkte RPC-Oberfläche für explizite Knotenbefehle.
• nodes invoke stellt system.run oder system.run.prepare nicht bereit; diese bleiben ausschließlich im Exec-Pfad.
• Der Exec-Pfad bereitet vor der Genehmigung einen kanonischen systemRunPlan vor. Sobald eine Genehmigung erteilt ist, leitet das Gateway diesen gespeicherten Plan weiter, nicht später vom Aufrufer bearbeitete command-/cwd-/session-Felder.
• system.notify beachtet den Status der Benachrichtigungsberechtigung in der macOS-App.
• Nicht erkannte platform-/deviceFamily-Metadaten eines Knotens verwenden eine konservative Standard-Allowlist, die system.run und system.which ausschließt. Wenn Sie diese Befehle absichtlich für eine unbekannte Plattform benötigen, fügen Sie sie explizit über gateway.nodes.allowCommands hinzu.
• system.run unterstützt --cwd, --env KEY=VAL, --command-timeout und --needs-screen-recording.
• Für Shell-Wrapper (bash|sh|zsh ... -c/-lc) werden anfragebezogene --env-Werte auf eine explizite Allowlist reduziert (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR).
• Bei „immer erlauben“-Entscheidungen im Allowlist-Modus speichern bekannte Dispatch-Wrapper (env, flock, nice, nohup, stdbuf, timeout) innere ausführbare Pfade statt Wrapper-Pfade. Wenn das Entpacken nicht sicher ist, wird automatisch kein Allowlist-Eintrag gespeichert.
• Auf Windows-Knotenhosts im Allowlist-Modus erfordern Shell-Wrapper-Läufe über cmd.exe /c eine Genehmigung (ein Allowlist-Eintrag allein erlaubt die Wrapper-Form nicht automatisch).
• system.notify unterstützt --priority <passive|active|timeSensitive> und --delivery <system|overlay|auto>.
• Knotenhosts ignorieren PATH-Überschreibungen und entfernen gefährliche Start-/Shell-Schlüssel (DYLD_*, LD_*, BASHOPTS, FPATH, KSH_ENV, NODE_OPTIONS, NODE_REDIRECT_WARNINGS, NODE_REPL_EXTERNAL_MODULE, NODE_REPL_HISTORY, NODE_V8_COVERAGE, PYTHON*, PERL*, RUBYOPT, SHELLOPTS, PS4, TCLLIBPATH). Wenn Sie zusätzliche PATH-Einträge benötigen, konfigurieren Sie die Dienstumgebung des Knotenhosts (oder installieren Sie Tools an Standardorten), statt PATH über --env zu übergeben.
• Im macOS-Knotenmodus wird system.run durch Exec-Genehmigungen in der macOS-App gesteuert (Einstellungen → Exec-Genehmigungen). Ask/Allowlist/Full verhalten sich wie beim Headless-Knotenhost; abgelehnte Aufforderungen geben SYSTEM_RUN_DENIED zurück.
• Auf dem Headless-Knotenhost wird system.run durch Exec-Genehmigungen gesteuert (~/.openclaw/exec-approvals.json).

Exec-Knotenbindung

Wenn mehrere Knoten verfügbar sind, können Sie Exec an einen bestimmten Knoten binden. Dies legt den Standardknoten für exec host=node fest (und kann pro Agent überschrieben werden).

Globaler Standard:

openclaw config set tools.exec.node "node-id-or-name"

Überschreibung pro Agent:

openclaw config get agents.listopenclaw config set 'agents.list[0].tools.exec.node' "node-id-or-name"

Zurücksetzen, um beliebige Knoten zu erlauben:

openclaw config unset tools.exec.nodeopenclaw config unset 'agents.list[0].tools.exec.node'

Berechtigungskarte

Knoten können eine permissions-Karte in node.list / node.describe enthalten, nach Berechtigungsname indiziert (z. B. screenRecording, accessibility) mit booleschen Werten (true = erteilt).

Headless-Knotenhost (plattformübergreifend)

OpenClaw kann einen Headless-Knotenhost (ohne UI) ausführen, der sich mit dem Gateway WebSocket verbindet und system.run / system.which bereitstellt. Dies ist auf Linux/Windows oder zum Ausführen eines minimalen Knotens neben einem Server nützlich.

Starten Sie ihn:

openclaw node run --host <gateway-host> --port 18789

Hinweise:

• Pairing ist weiterhin erforderlich (das Gateway zeigt eine Aufforderung zum Geräte-Pairing an).
• Der Knotenhost speichert seine Knoten-ID, sein Token, seinen Anzeigenamen und Gateway-Verbindungsinformationen in ~/.openclaw/node.json.
• Exec-Genehmigungen werden lokal über ~/.openclaw/exec-approvals.json erzwungen (siehe Exec-Genehmigungen).
• Unter macOS führt der Headless-Knotenhost system.run standardmäßig lokal aus. Setzen Sie OPENCLAW_NODE_EXEC_HOST=app, um system.run über den Exec-Host der Begleit-App zu leiten; fügen Sie OPENCLAW_NODE_EXEC_FALLBACK=0 hinzu, um den App-Host zu verlangen und geschlossen fehlzuschlagen, wenn er nicht verfügbar ist.
• Fügen Sie --tls / --tls-fingerprint hinzu, wenn der Gateway-WS TLS verwendet.

Mac-Knotenmodus

• Die macOS-Menüleisten-App verbindet sich als Knoten mit dem Gateway-WS-Server (sodass openclaw nodes … gegen diesen Mac funktioniert).
• Im Remote-Modus öffnet die App einen SSH-Tunnel für den Gateway-Port und verbindet sich mit localhost.