openclaw qr
Genera un QR de emparejamiento móvil y un código de configuración desde tu configuración actual de Gateway.
Opciones
--remote: prefieregateway.remote.url; recurre agateway.tailscale.mode=serve|funnelsi esa URL no está definida. IgnorapublicUrldel Plugindevice-pair.--url <url>: sobrescribe la URL del Gateway utilizada en la carga útil--public-url <url>: sobrescribe la URL pública utilizada en la carga útil--token <token>: sobrescribe el token del Gateway contra el que se autentica el flujo de arranque--password <password>: sobrescribe la contraseña del Gateway contra la que se autentica el flujo de arranque--setup-code-only: imprime solo el código de configuración--no-ascii: omite la representación ASCII del QR--json: emite JSON (setupCode,gatewayUrl,gatewayUrlsopcional,auth,urlSource)
--token y --password son mutuamente excluyentes.
Contenido del código de configuración
El código de configuración transporta unbootstrapToken opaco y de corta duración, no el token/contraseña compartido del Gateway. El flujo de arranque integrado emite:
- un token primario
nodeconscopes: [] - un token de transferencia
operatoracotado, limitado aoperator.approvals,operator.read,operator.talk.secretsyoperator.write
operator.admin siguen requiriendo un emparejamiento de operador aprobado por separado o un flujo de token.
Resolución de URL del Gateway
El emparejamiento móvil falla de forma cerrada con URL de Gatewayws:// públicas/Tailscale: usa Tailscale Serve/Funnel o una URL de Gateway wss:// para esos casos. Las direcciones LAN privadas y los hosts Bonjour .local siguen siendo compatibles mediante ws:// sin cifrar.
Cuando la URL de Gateway seleccionada proviene de gateway.bind=lan, OpenClaw también comprueba rutas persistentes de tailscale serve status --json. Cualquier raíz HTTPS de Serve que redirija al puerto local loopback del Gateway activo se incluye como alternativa. Los enlaces de interfaz específica custom y tailnet no reciben esa alternativa porque un proxy Serve de loopback no puede alcanzar esos listeners. Los clientes iOS actuales prueban las rutas anunciadas en orden y guardan la primera que sea alcanzable; el campo heredado url permanece sin cambios para clientes antiguos.
Con --remote, se requiere uno de gateway.remote.url o gateway.tailscale.mode=serve|funnel.
Resolución de autenticación (sin --remote)
Cuando no se pasa ninguna sobrescritura de autenticación de CLI, las SecretRefs de autenticación del Gateway local se resuelven así:
| Condición | Se resuelve como |
|---|---|
gateway.auth.mode="token", o modo inferido sin una fuente de contraseña ganadora | gateway.auth.token |
gateway.auth.mode="password", o modo inferido sin un token ganador desde auth/env | gateway.auth.password |
Tanto gateway.auth.token como gateway.auth.password están configurados (incluidas SecretRefs) y gateway.auth.mode no está definido | falla; define gateway.auth.mode explícitamente |
Resolución de autenticación (--remote)
Si las credenciales remotas efectivamente activas están configuradas como SecretRefs y no se pasa ni --token ni --password, el comando las resuelve desde la instantánea del Gateway activo. Si el Gateway no está disponible, el comando falla rápidamente.
Esta ruta de comando requiere un Gateway compatible con el método RPC
secrets.resolve. Los Gateway antiguos devuelven un error de método desconocido.