Guía completa de instalación de OpenClaw en Ubuntu 25.04 — De cero a chatear con Claude Opus 4.6

“La era de preguntarle a la IA ‘cómo hacer las cosas’ terminó. De ahora en adelante, es la era de hacer que la IA ‘haga las cosas por ti’.”

¿Has oído hablar de “OpenClaw (antes Clawdbot)”, el proyecto OSS que está dando mucho de qué hablar en GitHub? Ha habido tantos cambios de nombre que decidí hacer una instalación limpia desde cero.

En pocas palabras, piensa en él como “un mayordomo brillante que vive dentro de tu PC”. Solo tienes que hablarle a través de Slack o Discord, y se encargará de manera autónoma de todo tipo de tareas: manipular archivos en tu PC, administrar servidores, buscar información en la web, lo que sea.

¿El mayor atractivo? Se ejecuta localmente, no como un servicio en la nube. Tus datos se quedan en tus manos mientras construyes un entorno colaborativo con un compañero de IA confiable.

En este artículo, te guiaré a través de la instalación de OpenClaw. Vamos a instalarlo en Ubuntu 25.04, específicamente en una PC remota a la que accedemos por SSH.

Requisitos previos

• SO: Ubuntu 25.04 (PC remota vía SSH)
• Node.js: v24.x
• Autenticación: setup-token de Claude Code (no se requiere clave de API)

Objetivo

Llegar al punto donde puedas chatear con Claude Opus 4.6 usando openclaw tui.

Estructura del artículo

1. Fase 1: Instalación y compilación — clone → pnpm → build
2. Fase 2: Iniciando el Onboarding — Verificación de seguridad → QuickStart → clawdbot → migración a openclaw
3. Fase 3: Configuración del Onboarding — Selección de Modelo/Auth/Canal/Skills
4. Fase 4: La batalla contra el Token Mismatch — token mismatch → conflicto de puertos → adiós clawdbot-gateway
5. Fase 5: Resolución a la mañana siguiente — Un reinicio arregla las cosas, minas desactivadas
6. Fase 6: Configuración del CLI y autenticación — npm install -g → openclaw configure → setup-token
7. Fase 7: Verificación y toques finales — ui:build → conversación exitosa a través del tui

Fase 1: Instalación y compilación

Empecemos verificando tu versión de Node.

node -v
npm -v

Esto es lo que obtuve, y sobre esa advertencia de npm (spoiler: puedes ignorarla por ahora):

node -v npm -v v24.13.0 npm warn Unknown project config "allow-build-scripts". This will stop working in the next major version of npm. 11.6.2

El npm warn Unknown project config "allow-build-scripts"... significa:

• Hay una entrada allow-build-scripts en tu .npmrc del proyecto o personal
• Pero npm 11.x básicamente está diciendo “no tengo idea de qué es esa configuración”

…y eso es todo. Casi nunca es fatal en este punto.

Si quieres corregirlo (opcional):

# Revisa dónde está definido
npm config get userconfig
npm config get globalconfig

# Busca en la raíz del proyecto
ls -la .npmrc

# Si está en .npmrc, elimina o comenta la línea correspondiente

Ahora viene lo importante: clonar desde el repositorio oficial y entrar al directorio creado.

openclaw/openclaw: Tu asistente personal de IA. Cualquier SO. Cualquier plataforma. A la manera de la langosta. 🦞

git clone https://github.com/openclaw/openclaw.git
cd openclaw

A continuación, necesitamos configurar “pnpm”, la herramienta de gestión de paquetes necesaria para ejecutar el código de OpenClaw (es decir, instalarla).

corepack enable
pnpm -v || corepack prepare pnpm@latest --activate
pnpm -v

Este es el resultado: pnpm 10.23.0 está instalado, así que deberíamos poder avanzar directamente con dependencias → UI → build → onboard.

mamu@evo-x2:~/openclaw$ corepack enable mamu@evo-x2:~/openclaw$ pnpm -v || corepack prepare pnpm@latest --activate ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-10.23.0.tgz ? Do you want to continue? \[Y/n\] y

10.23.0 mamu@evo-x2:~/openclaw$ pnpm -v 10.23.0

Ahora que tenemos nuestra herramienta (pnpm) lista del paso anterior, es hora de pasar a “ensamblar (compilar) la aplicación OpenClaw en sí”.

Si lo comparamos con cocinar: “comprar los ingredientes (install), preparar el emplatado (ui:build) y terminar el platillo (build)”.

pnpm install
pnpm ui:build
pnpm build

Estos son los resultados. pnpm install → ui:build → build todos fueron exitosos. Lejos de “ejecutar comandos a ciegas esperando que funcione”, los logs se ven notablemente limpios.

mamu@evo-x2:~/openclaw$ pnpm install pnpm ui:build pnpm build Scope: all 34 workspace projects Lockfile is up to date, resolution step is skipped Packages: +1004 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

╭───────────────────────────────────────────────────╮ │ │ │ Update available! 10.23.0 → 10.28.2. │ │ Changelog: https://pnpm.io/v/10.28.2 │ │ To update, run: corepack use pnpm@10.28.2 │ │ │ ╰───────────────────────────────────────────────────╯

 WARN  Tarball download average speed 16 KiB/s (size 31 KiB) is below 50 KiB/s: https://registry.npmjs.org/@vitest/mocker/-/mocker-4.0.18.tgz (GET)edb-linux-x64-musl@0.23.0: 28.44 MB/48.03 MB Packages are hard linked from the content-addressable store to the virtual store. Content-addressable store is at: /home/mamu/.local/share/pnpm/store/v10 Virtual store is at: node\_modules/.pnpm Downloading @lancedb/lancedb-linux-x64-musl@0.23.0: 48.03 MB/48.03 MB, done Downloading @wasm-audio-decoders/opus-ml@0.0.2: 6.39 MB/6.39 MB, done Downloading @img/sharp-libvips-linux-x64@1.2.4: 7.53 MB/7.53 MB, done Downloading @img/sharp-libvips-linuxmusl-x64@1.2.4: 7.65 MB/7.65 MB, done Downloading @rolldown/binding-linux-x64-musl@1.0.0-rc.3: 8.26 MB/8.26 MB, done Downloading @napi-rs/canvas-linux-x64-gnu@0.1.90: 13.91 MB/13.91 MB, done Downloading pdfjs-dist@5.4.624: 9.97 MB/9.97 MB, done Downloading @lancedb/lancedb-linux-x64-gnu@0.23.0: 47.87 MB/47.87 MB, done Downloading @rolldown/binding-linux-x64-gnu@1.0.0-rc.3: 8.30 MB/8.30 MB, done Downloading node-llama-cpp@3.15.1: 28.13 MB/28.13 MB, done Downloading @typescript/native-preview-linux-x64@7.0.0-dev.20260205.1: 8.33 MB/8.33 MB, done Downloading @node-llama-cpp/linux-x64@3.15.1: 7.16 MB/7.16 MB, done Downloading ogg-opus-decoder@1.7.3: 6.87 MB/6.87 MB, done Downloading @napi-rs/canvas-linux-x64-musl@0.1.90: 13.30 MB/13.30 MB, done Downloading @oxlint/linux-x64-gnu@1.43.0: 5.25 MB/5.25 MB, done Downloading @node-llama-cpp/linux-x64-vulkan@3.15.1: 23.80 MB/23.80 MB, done Downloading @napi-rs/canvas-linux-x64-gnu@0.1.89: 13.88 MB/13.88 MB, done Downloading @oxlint-tsgolint/linux-x64@0.11.4: 11.62 MB/11.62 MB, done Downloading @napi-rs/canvas-linux-x64-musl@0.1.89: 13.28 MB/13.28 MB, done Downloading @node-llama-cpp/linux-x64-cuda@3.15.1: 121.76 MB/121.76 MB, done Downloading @node-llama-cpp/linux-x64-cuda-ext@3.15.1: 195.17 MB/195.17 MB, done Progress: resolved 1004, reused 0, downloaded 1003, added 1004, done node\_modules/.pnpm/protobufjs@7.5.4/node\_modules/protobufjs: Running postinstall script, done in 91ms node\_modules/.pnpm/node-llama-cpp@3.15.1\_typescript@5.9.3/node\_modules/node-llama-cpp: Running postinstall script... node\_modules/.pnpm/node-llama-cpp@3.15.1\_typescript@5.9.3/node\_modules/node-llama-cpp: Running postinstall script, done in 366msodules/.pnpm/protobufjs@6.8.8/node\_modules/protobufjs: Running postinstall script, done in 112ms node\_modules/.pnpm/esbuild@0.27.3/node\_modules/esbuild: Running postinstall script, done in 111ms node\_modules/.pnpm/protobufjs@8.0.0/node\_modules/protobufjs: Running postinstall script... node\_modules/.pnpm/protobufjs@8.0.0/node\_modules/protobufjs: Running postinstall script, done in 74mspto-nodejs: Running p node\_modules/.pnpm/@matrix-org+matrix-sdk-crypto-nodejs@0.4.0/node\_modules/@matrix-org/matrix-sdk-crypto-nodejs: Running postinstall script, done in 1s node\_modules/.pnpm/@whiskeysockets+baileys@7.0.0-rc.9\_audio-decode@2.2.3\_sharp@0.34.5/node\_modules/@whiskeysockets/baileysnode\_modules/.pnpm/@whiskeysockets+baileys@7.0.0-rc.9\_audio-decode@2.2.3\_sharp@0.34.5/node\_modules/@whiskeysockets/baileys: Running preinstall script, done in 54ms

dependencies: + @agentclientprotocol/sdk 0.14.1 + @aws-sdk/client-bedrock 3.984.0 + @buape/carbon 0.14.0 + @clack/prompts 1.0.0 + @grammyjs/runner 2.0.3 + @grammyjs/transformer-throttler 1.2.1 + @homebridge/ciao 1.3.4 + @larksuiteoapi/node-sdk 1.58.0 + @line/bot-sdk 10.6.0 + @lydell/node-pty 1.2.0-beta.3 + @mariozechner/pi-agent-core 0.52.6 + @mariozechner/pi-ai 0.52.6 + @mariozechner/pi-coding-agent 0.52.6 + @mariozechner/pi-tui 0.52.6 + @mozilla/readability 0.6.0 + @napi-rs/canvas 0.1.89 + @sinclair/typebox 0.34.47 + @slack/bolt 4.6.0 + @slack/web-api 7.13.0 + @whiskeysockets/baileys 7.0.0-rc.9 + ajv 8.17.1 + chalk 5.6.2 + chokidar 5.0.0 + cli-highlight 2.1.11 + commander 14.0.3 + croner 10.0.1 + discord-api-types 0.38.38 + dotenv 17.2.4 + express 5.2.1 + file-type 21.3.0 + grammy 1.39.3 + hono 4.11.7 + jiti 2.6.1 + json5 2.2.3 + jszip 3.10.1 + linkedom 0.18.12 + long 5.3.2 + markdown-it 14.1.0 + node-edge-tts 1.2.10 + node-llama-cpp 3.15.1 + osc-progress 0.3.0 + pdfjs-dist 5.4.624 + playwright-core 1.58.1 + proper-lockfile 4.1.2 + qrcode-terminal 0.12.0 + sharp 0.34.5 + signal-utils 0.21.1 + sqlite-vec 0.1.7-alpha.2 + tar 7.5.7 + tslog 4.10.2 + undici 7.20.0 + ws 8.19.0 + yaml 2.8.2 + zod 4.3.6

devDependencies: + @grammyjs/types 3.23.0 + @lit-labs/signals 0.2.0 + @lit/context 1.1.6 + @types/express 5.0.6 + @types/markdown-it 14.1.2 + @types/node 25.2.1 + @types/proper-lockfile 4.1.4 + @types/qrcode-terminal 0.12.2 + @types/ws 8.18.1 + @typescript/native-preview 7.0.0-dev.20260205.1 + @vitest/coverage-v8 4.0.18 + lit 3.3.2 + ollama 0.6.3 + oxfmt 0.28.0 + oxlint 1.43.0 + oxlint-tsgolint 0.11.4 + rolldown 1.0.0-rc.3 + tsdown 0.20.3 + tsx 4.21.0 + typescript 5.9.3 + vitest 4.0.18

╭ Warning ───────────────────────────────────────────────────────────────────────────────────╮ │ │ │ Ignored build scripts: core-js. │ │ Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts. │ │ │ ╰────────────────────────────────────────────────────────────────────────────────────────────╯

. prepare$ command -v git >/dev/null 2>&1 && git config core.hooksPath git-hooks || exit 0 └─ Done in 46ms Done in 17.9s using pnpm v10.23.0

> openclaw@2026.2.4 ui:build /home/mamu/openclaw > node scripts/ui.js build

> openclaw-control-ui@ build /home/mamu/openclaw/ui > vite build

vite v7.3.1 building client environment for production... ✓ 127 modules transformed. ../dist/control-ui/index.html 0.69 kB │ gzip: 0.37 kB ../dist/control-ui/assets/index-BoXosYY6.css 80.85 kB │ gzip: 13.95 kB ../dist/control-ui/assets/index-Dm6g1E26.js 538.46 kB │ gzip: 135.21 kB │ map: 1,475.17 kB

(!) Some chunks are larger than 500 kB after minification. Consider: - Using dynamic import() to code-split the application - Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks - Adjust chunk size limit for this warning via build.chunkSizeWarningLimit. ✓ built in 649ms

> openclaw@2026.2.4 build /home/mamu/openclaw > pnpm canvas:a2ui:bundle && tsdown && node --import tsx scripts/canvas-a2ui-copy.ts && node --import tsx scripts/copy-hook-metadata.ts && node --import tsx scripts/write-build-info.ts && node --import tsx scripts/write-cli-compat.ts

> openclaw@2026.2.4 canvas:a2ui:bundle /home/mamu/openclaw > bash scripts/bundle-a2ui.sh

✔ Build complete in 3789ms
✔ Build complete in 3769ms
✔ Build complete in 3791ms

[copy-hook-metadata] Copied boot-md/HOOK.md [copy-hook-metadata] Copied command-logger/HOOK.md [copy-hook-metadata] Copied session-memory/HOOK.md [copy-hook-metadata] Copied soul-evil/HOOK.md [copy-hook-metadata] Done

Qué significan esas “advertencias” (solo lo importante)

1) Update available! 10.23.0 → 10.28.2

Solo es pnpm avisándote que hay una actualización. Ignóralo por ahora (si funciona, no lo toques). Si te molesta, ejecútalo después:

corepack use pnpm@10.28.2
pnpm -v

2) Tarball download average speed ... below 50 KiB/s

Solo una advertencia de “estuvo lento”. No falló, así que estamos bien.

3) Ignored build scripts: core-js / pnpm approve-builds

Esta es la más importante.

• Las versiones recientes de pnpm tienden a bloquear los scripts postinstall / build de las dependencias por defecto como medida de seguridad
• Esto significa que el script de core-js fue omitido
• En la mayoría de los casos, ignorar core-js no causa problemas reales (aunque dependiendo del proyecto, ocasionalmente puede hacer que tests o ciertas funcionalidades fallen después)

Si quieres ir a lo seguro, ejecuta esto una vez para aprobar selectivamente lo que necesites:

pnpm approve-builds

(Si aparece core-js, generalmente es seguro aprobarlo. Pero si eres de los precavidos, “apruébalo solo si algo falla” también funciona.)

Fase 2: Iniciando el Onboarding

La compilación terminó, así que lo siguiente es onboard → inicio del daemon (gateway).

pnpm openclaw onboard --install-daemon
pnpm openclaw gateway status
pnpm openclaw dashboard

🦞 OpenClaw 2026.2.4 (c75275f) — iMessage green bubble energy, but for everyone.

│ ◇ Doctor changes ───────────────────────────────────────────────────────────────────────╮ │ │ │ - State dir: /home/mamu/.clawdbot → /home/mamu/.openclaw (legacy path now symlinked) │ │ │ ├────────────────────────────────────────────────────────────────────────────────────────╯ ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ ██░▄▄▄░██░▄▄░██░▄▄▄██░▀██░██░▄▄▀██░████░▄▄▀██░███░██ ██░███░██░▀▀░██░▄▄▄██░█░█░██░█████░████░▀▀░██░█░█░██ ██░▀▀▀░██░█████░▀▀▀██░██▄░██░▀▀▄██░▀▀░█░██░██▄▀▄▀▄██ ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ 🦞 OPENCLAW 🦞 ┌ OpenClaw onboarding │ ◇ Security ──────────────────────────────────────────────────────────────────────────────╮ │ │ │ Security warning — please read. │ │ │ │ OpenClaw is a hobby project and still in beta. Expect sharp edges. │ │ This bot can read files and run actions if tools are enabled. │ │ A bad prompt can trick it into doing unsafe things. │ │ │ │ If you're not comfortable with basic security and access control, don't run OpenClaw. │ │ Ask someone experienced to help before enabling tools or exposing it to the internet. │ │ │ │ Recommended baseline: │ │ - Pairing/allowlists + mention gating. │ │ - Sandbox + least-privilege tools. │ │ - Keep secrets out of the agent's reachable filesystem. │ │ - Use the strongest available model for any bot with tools or untrusted inboxes. │ │ │ │ Run regularly: │ │ openclaw security audit --deep │ │ openclaw security audit --fix │ │ │ │ Must read: https://docs.openclaw.ai/gateway/security │ │ │ ├─────────────────────────────────────────────────────────────────────────────────────────╯ │ ◆ I understand this is powerful and inherently risky. Continue? │ ○ Yes / ● No

Lo primero: selecciona Yes en esta pantalla

Lo que estás viendo es una confirmación que dice “¿Entiendes que esto es riesgoso? ¿De verdad quieres continuar?” A menos que selecciones Yes aquí, el daemon no se instalará y el gateway no arrancará.

Que no se abra el navegador es completamente normal — solo ábrelo manualmente

pnpm openclaw dashboard puede fallar al intentar abrir un navegador automáticamente dependiendo de tu entorno (por SSH / sin GUI / xdg-open no configurado / problemas con Wayland), así que solo abre la URL tú mismo.

Después de completar todo el onboarding, ejecuta esto primero:

pnpm openclaw gateway status

Verifica que diga running.

Luego, para obtener la URL del dashboard y abrirla tú mismo:

pnpm openclaw dashboard --print-url

(Si --print-url no existe, la URL debería aparecer en los logs cuando ejecutes dashboard. Si no aparece, salta directamente a “Verificación de puertos” más abajo.)

Verifica si el daemon se instaló (systemd)

Como usaste --install-daemon, en la mayoría de los casos se habrá creado un servicio de usuario systemd.

systemctl --user status openclaw-gateway.service --no-pager

Si no está corriendo:

systemctl --user restart openclaw-gateway.service
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Lista rápida cuando el dashboard sigue sin aparecer

1) Verifica qué puertos están escuchando

(El puerto por defecto del dashboard de OpenClaw puede variar según el entorno, así que empieza verificando qué está realmente en LISTEN)

ss -lntp | grep -E 'openclaw|node' | head -n 20

2) Revisa los logs de OpenClaw

pnpm openclaw gateway logs --tail 200

Una nota sobre seguridad (prácticas mínimas de operación segura para responder a la advertencia del onboarding)

Como dice la pantalla, solo sigue estas indicaciones básicas y estarás bien por ahora:

• No lo expongas externamente (solo localhost, para empezar)
• Empieza con las herramientas al mínimo / desactivadas
• Si haces alguna integración, configura una lista de permitidos / mention gating primero (no dejes que actúe por su cuenta)

Qué hacer a continuación (en este orden)

1. Selecciona Yes en la pantalla de onboarding
2. Una vez que termine, ejecuta: pnpm openclaw gateway status systemctl --user status openclaw-gateway.service --no-pager
3. Muestra la URL del dashboard y ábrela tú mismo: pnpm openclaw dashboard --print-url

En este punto, lo que muestran los logs es que simplemente está pausado a mitad del onboarding. Cuando ingreses yes, verás:

◇ I understand this is powerful and inherently risky. Continue? │ Yes │ ◆ Onboarding mode │ ● QuickStart (Configure details later via openclaw configure.) │ ○ Manual

Espera, ¿realmente necesito el comando del navegador?

Básicamente: no. Porque estás conectado por SSH. El navegador (dashboard) es solo una interfaz visual de gestión — OpenClaw funciona perfectamente siempre y cuando el CLI y el daemon (gateway) estén ejecutándose.

Cuándo sí necesitarías el navegador (dashboard)

• Emparejamiento (QR/auth) o cuando quieras hacer la configuración inicial a través de una GUI
• Cuando quieras verificar visualmente el estado de los canales/conexiones
• Cuando quieras hacer clic en las configuraciones (a veces es más fácil que el CLI)

Dicho de otra forma, los usuarios experimentados rutinariamente operan sin abrir el dashboard nunca.

Flujo de trabajo sin navegador (solo CLI)

Como mínimo, esto es todo lo que necesitas:

pnpm openclaw gateway status
pnpm openclaw doctor
pnpm openclaw security audit --deep
pnpm openclaw logs --tail 200   # si está disponible; si no, usa gateway logs

Si el daemon está vivo, todo está en orden:

systemctl --user status openclaw-gateway.service --no-pager

¿Para qué sirve el “comando del navegador” entonces?

openclaw dashboard es solo una función de conveniencia que:

• Levanta la URL local
• Intenta abrir un navegador usando algo como xdg-open

Eso es todo. En entornos donde eso no funciona (SSH / sin GUI), naturalmente va a fallar — así que no te preocupes.

Enfoque recomendado para tu situación actual

Primero, levanta el gateway / haz el emparejamiento / asegura los permisos vía CLI. El dashboard es para “cuando tengas ganas de verlo”.

Aquí, ir con QuickStart está bien. Todo lo que esta pantalla te pregunta es “¿cuánta configuración inicial quieres hacer ahora mismo?”

¿Cuál deberías elegir?

QuickStart (recomendado)

• El camino más rápido para “solo ponerlo a funcionar”
• Puedes ajustar todo después con openclaw configure
• Te lleva a un estado donde el gateway/daemon está arriba y puedes interactuar con él localmente

Manual (no es necesario ahora)

• Para quienes quieren dejar todo definido desde el principio — conexiones (Slack/Discord/etc.), permisos, herramientas, almacenamiento, modelos, todo
• Elige esto si quieres ponerte serio con el diseño de seguridad desde el inicio

En nuestro caso, el objetivo es “reinstalar y volver a funcionar”, así que QuickStart es la única opción razonable.

Por qué fue necesaria la “reinstalación” (cambió el nombre)

Como mostraron los logs:

• El directorio de estado cambió de /home/mamu/.clawdbot → /home/mamu/.openclaw (el antiguo se rescata mediante un symlink)

En otras palabras, como el nombre del proyecto cambió, las ubicaciones del daemon y la configuración también se movieron, así que onboard simplemente está reconstruyendo el “arranque bajo el nuevo régimen”.

Esto puede parecer sospechoso, pero es totalmente normal. La razón es simple: OpenClaw muy probablemente está haciendo algo donde “recrea .clawdbot automáticamente para compatibilidad con la ruta antigua”.

El mensaje del log decía exactamente esto:

State dir: /home/mamu/.clawdbot → /home/mamu/.openclaw (legacy path now symlinked)

En otras palabras, la filosofía es “si la ruta antigua no existe, créala de todos modos y pon un symlink ahí”.

Primero, confirmemos: ¿no es un “symlink” en lugar de un “directorio”?

Este único comando te dice todo:

ls -la ~/.clawdbot ~/.openclaw
readlink -f ~/.clawdbot 2>/dev/null || true

Lo que esperarías ver:

• ~/.openclaw es el directorio real
• ~/.clawdbot -> /home/mamu/.openclaw es un symlink

Si es así, tenías razón al eliminarlo antes, y el onboarding simplemente “lo trajo de vuelta por compatibilidad”.

mamu@evo-x2:~/openclaw$ ls -la ~/.clawdbot ~/.openclaw readlink -f ~/.clawdbot 2>/dev/null || true lrwxrwxrwx 1 mamu mamu 20 Feb 6 20:28 /home/mamu/.clawdbot -> /home/mamu/.openclaw

/home/mamu/.openclaw: total 16 drwxrwxr-x 3 mamu mamu 4096 Feb 6 17:29 . drwxr-x--x 28 mamu mamu 4096 Feb 6 20:28 .. drwxrwxr-x 2 mamu mamu 4096 Feb 6 17:29 cron -rw-rw-r-- 1 mamu mamu 49 Feb 6 17:29 update-check.json /home/mamu/.openclaw

¿Ves? .clawdbot no es un directorio real, es un symlink, así que aunque lo eliminaste antes, OpenClaw simplemente lo recreó por compatibilidad.

/home/mamu/.clawdbot -> /home/mamu/.openclaw

Entonces la comprensión correcta en este momento es:

• Los datos reales (directorio de estado) viven en ~/.openclaw
• ~/.clawdbot es solo una “entrada” que se mantiene para que las referencias de configuración antiguas sigan funcionando

Además, los contenidos de .openclaw son solo cron/ y update-check.json, así que todavía está totalmente limpio.

¿Puedo eliminarlo?

La cuestión es esta:

• Si solo vas a usar OpenClaw en adelante, .clawdbot debería ser innecesario (se mantiene solo por compatibilidad)
• Pero otras herramientas o scripts antiguos podrían seguir haciendo referencia a .clawdbot, así que operativamente es más seguro dejarlo

Si realmente quieres tener todo ordenado, revisa los contenidos y las referencias primero. En resumen:

• Eliminar .clawdbot está básicamente bien (OpenClaw usa .openclaw como la ubicación real)
• Pero algunas personas podrían tener problemas en el momento en que desaparezca — específicamente, cualquiera que tenga algo de la era antigua de clawdbot (scripts/servicios/configuraciones) que haga referencia a .clawdbot

Las personas que “migraron como una actualización” son exactamente las que están en riesgo aquí.

¿Y si sí apareciera como un directorio real?

Por ejemplo, si ~/.clawdbot/ es un directorio normal con contenido real adentro.

En ese caso, OpenClaw puede haber creado el directorio en la primera ejecución como parte de la migración viejo-a-nuevo, u otra cosa referenció la ruta antigua y lo generó.

Para verificar:

file ~/.clawdbot
du -sh ~/.clawdbot ~/.openclaw 2>/dev/null

El enfoque más seguro (recomendado)

• Trata .openclaw como la ubicación canónica (real)
• Deja .clawdbot como un symlink de compatibilidad

Eso es todo. Listo.

Fase 3: Configuración del Onboarding

Continuando con QuickStart llegas a…

◇ I understand this is powerful and inherently risky. Continue? │ Yes │ ◇ Onboarding mode │ QuickStart │ ◇ QuickStart ─────────────────────────╮ │ │ │ Gateway port: 18789 │ │ Gateway bind: Loopback (127.0.0.1) │ │ Gateway auth: Token (default) │ │ Tailscale exposure: Off │ │ Direct to chat channels. │ │ │ ├──────────────────────────────────────╯ │ ◆ Model/auth provider │ ● xAI (Grok) (API key) │ ○ OpenAI │ ○ Anthropic │ ○ MiniMax │ ○ Moonshot AI (Kimi K2.5) │ ○ Google │ ○ OpenRouter │ ○ Qwen │ ○ Z.AI (GLM 4.7) │ ○ Copilot │ ○ Vercel AI Gateway │ ○ OpenCode Zen │ ○ Xiaomi │ ○ Synthetic │ ○ Venice AI │ ○ Cloudflare AI Gateway │ ○ Skip for now

El comando del navegador no es necesario (se trató en la Fase 2). Solo abre la URL manualmente. La URL del Dashboard se verá así: http://127.0.0.1:18789/?token=....

¿Qué es “Model/auth provider”? (Esto es independiente de la configuración de Codex / Claude Code)

Lo que estás eligiendo aquí es el “proveedor de LLM” al que OpenClaw le hará consultas.

• Claude Code y Codex son “herramientas CLI / de desarrollo separadas” — son algo diferente de lo que OpenClaw usa automáticamente a través de esta pantalla.
• Lo que OpenClaw necesita saber es “¿a qué API de LLM (o API compatible) debo enviar las solicitudes?”

¿Cómo elegir en esta situación?

En nuestro entorno:

• Codex y Claude Code están instalados.
• Qwen se ejecuta localmente
• Pero las opciones en esta pantalla incluyen OpenAI/Anthropic/Qwen/OpenRouter… y más

Patrón A: Ponerlo a funcionar lo antes posible (camino más rápido)

Selecciona “Skip for now” para terminar el onboarding → ajusta después con openclaw configure. Esta es la opción más segura y confiable. Es mejor confirmar que arranca antes que equivocarte con una clave de API y causar problemas.

Patrón B: Usar una API en la nube (elige la que tengas)

• ¿Tienes una clave de Claude? → Anthropic
• ¿Tienes una clave de OpenAI? → OpenAI
• ¿Tienes una clave de OpenRouter? → OpenRouter

Patrón C: Usar Qwen local (ojo con esto)

El “Qwen” en este menú muy probablemente se refiere al servicio en la nube de Qwen (DashScope / Model Studio, etc.), no a tu Qwen local — va a pedir una clave de API.

La forma típica de conectar Qwen local a OpenClaw es:

• Ejecutarlo vía Ollama / vLLM / llama.cpp como un endpoint compatible con OpenAI
• Del lado de OpenClaw, configurarlo como OpenAI (compatible) y cambiar la base_url (es decir: seleccionar “Qwen” en esta pantalla no va a apuntar mágicamente a tu instancia local)

Así que si Qwen local es tu prioridad, Skip for now y termina el onboarding → configura después. Menos probabilidad de que algo salga mal.

Siguiente paso (pasos recomendados)

1. Sigue con QuickStart (Loopback + Token es exactamente lo correcto. No exponerlo externamente es el camino)
2. Para el proveedor, elige Skip for now (solo confirma que arranca primero)
3. Después de que termine el onboarding, ejecuta lo siguiente para verificar el estado:
   • pnpm openclaw gateway status
   • pnpm openclaw dashboard (si no se abre, navega manualmente a la URL que imprime)

La pregunta de “¿recrea clawdbot?” (conclusión: no lo está “creando” — lo está “preservando por compatibilidad”)

Como viste, se crea un symlink ~/.clawdbot -> ~/.openclaw. Esto es solo compatibilidad para que las referencias a la ruta antigua no se rompan. Y sí, “eliminarlo podría causar problemas a quienes actualizaron desde la versión anterior” es exactamente correcto.

Una última cosa: ¿tengo que configurar Codex / Claude Code?

No necesitas configurarlos en esta pantalla de onboarding. Primero lo primero: que el gateway/daemon de OpenClaw funcione normalmente.

Después de eso:

• Configura “a qué modelo enviar las solicitudes (API / compatible local)” para OpenClaw
• Luego si es necesario, agrega “habilidades de programación/integraciones (Codex / Claude Code)”

Ese orden minimiza la posibilidad de que algo salga mal.

Después de seleccionar Skip for now…

◇ Model/auth provider │ Skip for now │ ◆ Filter models by provider │ ● All providers │ ○ amazon-bedrock │ ○ anthropic │ ○ azure-openai-responses │ ○ cerebras │ ○ github-copilot │ ○ google │ ○ google-antigravity │ ○ google-gemini-cli │ ○ google-vertex │ ○ groq │ ○ huggingface │ ○ kimi-coding │ ○ minimax │ ○ minimax-cn │ ○ mistral │ ○ openai │ ○ openai-codex │ ○ opencode │ ○ openrouter │ ○ vercel-ai-gateway │ ○ xai │ ○ zai

Incluso con Skip for now, te obliga a elegir una “lista de modelos” — así parece funcionar. Esto no es “ingresa tu clave ahora” — es más como un filtro para delimitar qué proveedores podrías usar después.

¿Cómo elegir aquí?

En resumen: simplemente déjalo en All providers y avanza

El razonamiento es sencillo: no has ingresado ninguna clave todavía, y el objetivo es terminar QuickStart. Puedes cambiar la configuración después. All providers → siguiente es lo más rápido y seguro.

Pero si quieres ser más intencional

Si prefieres “no tener que pensar en esto después”, elegir un filtro de proveedor sigue la misma lógica de los Patrones A/B/C de arriba. Para Codex, openai-codex es lo más cercano; para Claude Code, anthropic; para Qwen local, openai (endpoint compatible).

Un detalle: qwen no está en la lista, así que Qwen local tendrá que conectarse como “compatible con OpenAI” de todas formas.

¿Qué hacemos esta vez entonces?

“Solo quiero que funcione” + “Ajustaré la configuración después” → Déjalo en All providers y avanza. Esa es la ruta más rápida y segura. Puedes cambiar el filtro en cualquier momento — es solo actualizar una configuración en ~/.openclaw.

Después de dejarlo en All providers y avanzar, aparece la pantalla de selección de modelo predeterminado:

◇ Filter models by provider │ All providers │ ◆ Default model │ ● Keep current (default: anthropic/claude-opus-4-6) │ ○ Enter model manually │ ○ amazon-bedrock/anthropic.claude-3-haiku-20240307-v1:0 │ ○ amazon-bedrock/anthropic.claude-3-5-haiku-20241022-v1:0 │ ...

¿Qué deberías elegir aquí?

Si “no he ingresado ninguna clave todavía / solo quiero que funcione”, la opción óptima es:

Keep current (default: anthropic/claude-opus-4-6) y avanzar

Razonamiento: sin autenticación no podrá llamar al modelo de todos modos, y puedes cambiarlo después. “Keep current” es la decisión correcta cuando la prioridad es arrancar.

Dicho esto: anticipemos lo que podría complicarse después

Consulta los Patrones A/B/C arriba para elegir tu ruta de autenticación. Aquí solo el desglose de prioridades:

1) Quieres usar Claude Code (mi elección)

• Dejarlo en el actual anthropic/claude-opus-4-6 está bien (aunque necesitarás configurar autenticación/enrutamiento de Anthropic después)

2) Quieres usar Codex

• Irías a Enter model manually y lo apuntarías hacia openai-codex/... (lo que aparezca en la lista) Pero como no tienes clave ahora, prioriza que funcione primero.

3) Quieres usar Qwen local

• Esta lista parece ser mayormente “centrada en proveedores de nube”, así que Qwen local probablemente necesitará configurarse como una “API compatible con OpenAI” mapeada a openai/...
• Es decir, es más confiable configurarlo después poniendo base_url / api_key (dummy) / nombre del modelo en el archivo de configuración, en lugar de intentar elegirlo aquí

Después de seleccionar Keep current (default: anthropic/claude-opus-4-6), aparece la pantalla de selección de canal:

◇ Default model │ Keep current (default: anthropic/claude-opus-4-6) │ ◇ Model check ───────────────────────────────────────────────────────────────────────────╮ │ │ │ No auth configured for provider "anthropic". The agent may fail until credentials are │ │ added. │ │ │ ├─────────────────────────────────────────────────────────────────────────────────────────╯ │ ◇ Channel status ────────────────────────╮ │ │ │ Telegram: not configured │ │ WhatsApp: not configured │ │ Discord: not configured │ │ Google Chat: not configured │ │ Slack: not configured │ │ Signal: not configured │ │ iMessage: not configured │ │ ... │ ├─────────────────────────────────────────╯ │ ◆ Select channel (QuickStart) │ ● Telegram (Bot API) (not configured) │ ○ WhatsApp (QR link) │ ○ Discord (Bot API) │ ... │ ○ Skip for now

Qué está pasando ahora mismo (en resumen)

1) La autenticación del modelo (Anthropic) no está configurada

No auth configured for provider "anthropic" — Esto dice “el predeterminado es anthropic/claude-opus… pero no tienes clave ni inicio de sesión, así que ese modelo realmente no se puede llamar. Probablemente falle después”.

2) Los canales (Telegram/Discord/Slack, etc.) no están configurados

Ahora mismo está en la etapa de “¿de dónde debería recibir mensajes?”

La elección óptima aquí

“Solo quiero verificar que funcione” + “SSH” + “no quiero exponerlo externamente” + “no tengo claves todavía” → Skip for now es la respuesta.

Ve con esto por ahora: Select channel (QuickStart) → Skip for now

Razones:

• Puedes configurar canales después en cualquier momento
• Si eliges Telegram ahora, te va a pedir un token de BotFather y te vas a atascar
• Por SSH, el “dashboard” no se va a abrir automáticamente de todas formas, así que confirmar que el daemon/gateway está corriendo debería ser primero

Qué hacer después (verificar “¿está vivo?”)

Una vez que termines todo el onboarding, verifica con pnpm openclaw gateway status / pnpm openclaw doctor igual que en la Fase 2. El navegador no es necesario para flujos de trabajo por SSH (si quieres verlo, usa port forwarding por SSH — más sobre eso después).

“¿Y cuándo configuro la autenticación del modelo?”

Después de confirmar que arranca. El orden es Skip for now → verificar gateway → decidir la ruta de autenticación (Patrones A/B/C como se discutió arriba).

Notas rápidas sobre lo que podría trabarte en la pantalla actual

• Telegram: Casi seguro va a pedir un token de Bot
• Discord/Slack: Requiere registro de aplicación (es un poco elaborado)
• Skip for now: El camino más rápido a “verificación de arranque local”

Después de seleccionar Skip for now para el canal, aparece el mensaje de configuración de skills:

◇ Select channel (QuickStart) │ Skip for now Updated ~/.clawdbot/openclaw.json Workspace OK: ~/.openclaw/workspace Sessions OK: ~/.openclaw/agents/main/sessions │ ◇ Skills status ────────────╮ │ │ │ Eligible: 6 │ │ Missing requirements: 44 │ │ Blocked by allowlist: 0 │ │ │ ├────────────────────────────╯ │ ◆ Configure skills now? (recommended) │ ● Yes / ○ No

El onboarding ha llegado al punto donde la base está en su lugar. Basándonos en lo que hay en pantalla, lo más importante ahora es “no amontonar skills (= permisos de ejecución) cuando no tienes claves (auth) ni canales configurados todavía”.

Qué significa la pantalla actual (puntos clave)

• Model check: No hay auth para anthropic → con esta configuración el modelo predeterminado (Claude Opus) no se puede llamar, y probablemente falle después
• Channel: Todos sin configurar → no se ha decidido de dónde recibir mensajes
• openclaw.json actualizado: La configuración se escribió en ~/.clawdbot/openclaw.json (el archivo real vive en ~/.openclaw)
• Skills status:
  • Eligible: 6 (solo 6 skills se pueden activar en el entorno actual)
  • Missing requirements: 44 (44 skills no se pueden usar por dependencias/claves/etc. faltantes)

Qué hacer aquí (recomendación)

Ve con “No” — el camino más seguro y rápido

Configure skills now? → No

Razones:

• Auth (claves) y canales siguen sin configurar
• Las skills son un punto de entrada para “leer archivos, ejecutar comandos, etc.” → Mejor asegurar primero la verificación de arranque y el diseño de autenticación para evitar accidentes

Qué viene después (la jugada ganadora para configuraciones SSH)

Una vez que salgas del onboarding, verifica con pnpm openclaw gateway status / doctor (como se describió antes). Elegir tu ruta de autenticación (Patrones A/B/C) viene después de eso, y las skills vienen todavía después. El orden estable es auth → canales → skills.

Después de seleccionar No, aparecen la pantalla de hooks (sin hooks disponibles), el runtime del servicio gateway, y luego el error de token mismatch:

◇ Configure skills now? (recommended) │ No │ ◇ Hooks ... │ ◇ No Hooks Available ... │ ◇ Gateway service runtime ... │ ◐ Installing Gateway service… Installed systemd service: /home/mamu/.config/systemd/user/openclaw-gateway.service ◇ Gateway service installed. │ gateway connect failed: Error: unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token) ◇ Health check failed: gateway closed (1008): unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token) Gateway target: ws://127.0.0.1:18789 Source: local loopback Config: /home/mamu/.openclaw/openclaw.json Bind: loopback

Fase 4: La batalla contra el Token Mismatch

Los logs lo dicen todo:

• unauthorized: gateway token mismatch (set gateway.remote.token to match gateway.auth.token)
• gateway closed (1008): unauthorized
• invalid connect params: at /client/id ...

En otras palabras:

1. El token que espera el gateway (gateway.auth.token)
2. El token que tiene el cliente (gateway.remote.token)

Estos dos no coinciden. Como el proceso de onboard instaló un servicio systemd (el gateway) a medio camino, es común terminar con un desajuste donde “solo un lado recibió la nueva configuración”.

Lo primero: hacer que los tokens coincidan en el archivo de configuración

Dicho esto, también puedes simplemente elegir Yes para continuar por ahora y arreglarlo después. El archivo de configuración está en la ruta que muestran los logs:

/home/mamu/.openclaw/openclaw.json

Primero, revisa su contenido:

cat ~/.openclaw/openclaw.json | sed -n '1,200p'

Luego busca la sección gateway (grep funciona bien):

grep -n '"gateway"' -n ~/.openclaw/openclaw.json
grep -n 'auth' ~/.openclaw/openclaw.json
grep -n 'remote' ~/.openclaw/openclaw.json
grep -n 'token' ~/.openclaw/openclaw.json

Lo que quieres ver (conceptualmente):

• gateway.auth.token existe
• gateway.remote.token existe
• Ambos son exactamente iguales

Arréglalo a mano (la forma más rápida)

Ábrelo en un editor:

nano ~/.openclaw/openclaw.json

Copia el valor de gateway.auth.token y pégalo en gateway.remote.token. (Si solo uno de los dos existe, simplemente ponles el mismo valor a ambos.)

Después de arreglarlo: reinicia el servicio gateway

Está instalado como un servicio systemd de usuario, así que usa --user:

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager -l

Revisa los logs también:

journalctl --user -u openclaw-gateway.service -n 80 --no-pager

Verificación de conexión (sin necesidad de navegador)

Por SSH, esto es todo lo que necesitas:

pnpm openclaw gateway status
pnpm openclaw doctor

Si solo quieres verificar la conectividad básica, prueba el lado HTTP:

curl -I http://127.0.0.1:18789/ | head

Sobre “/client/id must be equal to constant”

Esto generalmente aparece junto con desajustes en los parámetros de conexión (client id / token / handshake). En la mayoría de los casos, desaparece solo una vez que corriges los tokens y reinicias.

Una última pregunta: ¿bash completion?

Enable bash shell completion for openclaw?

Yes está bien. Es inofensivo — solo habilita el autocompletado con tab. (Si te preocupa, elegir No tampoco afectará nada.)

Después de elegir Yes, aparece la pantalla de finalización del onboard:

◇ Enable bash shell completion for openclaw? │ Yes │ ◇ Shell completion ... │ ◇ Dashboard ready ───────────────────────────────────────────────────────╮ │ │ │ Dashboard link: http://127.0.0.1:18789/ │ │ Copy/paste this URL in a browser on this machine to control OpenClaw. │ │ No GUI detected. Open from your computer: │ │ ssh -N -L 18789:127.0.0.1:18789 mamu@192.168.0.108 │ │ Then open: │ │ http://localhost:18789/ │ │ ... │ ├─────────────────────────────────────────────────────────────────────────╯ │ └ Onboarding complete. Use the dashboard link above to control OpenClaw.

Esto te está diciendo que lo abras en un navegador — pero no en un navegador del servidor. Significa abrirlo en un navegador de tu máquina local (ya que estás conectado por SSH).

Qué hacer ahora mismo (camino más corto)

Abre el dashboard vía port forwarding por SSH. Si usas Remote-SSH de VS Code, el port forwarding podría ya estar funcionando automáticamente. Para configurar el túnel manualmente desde PowerShell:

ssh -N -L 18789:127.0.0.1:18789 mamu@192.168.0.108

Luego abre http://localhost:18789/ en tu navegador local. Puedes configurar y verificar cosas vía CLI sin navegador, pero honestamente, es más fácil con el navegador.

Sin embargo: ese “token mismatch” matará el dashboard si lo ignoras

Si el token mismatch de antes sigue ahí, la interfaz solo mostrará errores rojos cuando la abras. Configura el túnel primero, verifica en el navegador, y si ves “unauthorized”, ve a arreglar los tokens.

Pero entonces te encuentras con esto en el navegador:

Control UI assets not found. Build them with pnpm ui:build (auto-installs UI deps), or run pnpm ui:dev during development.

Esto simplemente significa que la UI (archivos estáticos) no se ha compilado todavía, o el gateway no puede encontrarlos donde los espera. Los logs anteriores decían “Control UI assets missing; building…” pero o se interrumpió a medio camino o la salida de la compilación terminó en un lugar inesperado. Presiona Ctrl+C para detener el asistente por ahora.

Causa raíz encontrada

Gateway failed to start: another gateway instance is already listening on ws://127.0.0.1:18789
...
- pid 2128 mamu: clawdbot-gateway (127.0.0.1:18789)
- Another process is listening on this port.

Misma conclusión: el puerto 18789 está ocupado por “pid 2128 clawdbot-gateway”. OpenClaw no está roto — simplemente el asiento ya está ocupado.

Solución: desalojar al viejo clawdbot-gateway que está acaparando el puerto 18789

1) Primero, detén lo que esté ocupando el puerto

El culpable es pid 2128, clawdbot-gateway, que está en LISTEN en 18789. Detén el proceso y confirma que el puerto queda libre.

# Verifica qué PID tiene 18789 (omite si ya lo sabes)
ss -ltnp | grep 18789

# Detén el gateway viejo
kill 2128

# Confirma que está libre
ss -ltnp | grep 18789 || echo "OK: 18789 freed"

Si ves OK: 18789 freed, la primera etapa está resuelta.

2) Importante: si vuelve después de matarlo, systemd lo está reviviendo

Si kill funciona pero el mismo PID (o uno nuevo) reaparece en segundos, el clawdbot viejo tiene un servicio systemd de usuario configurado para mantenerlo vivo.

Busca las unidades de clawdbot

systemctl --user list-units --type=service | grep -Ei 'clawdbot|claw'
systemctl --user list-unit-files | grep -Ei 'clawdbot|claw'

Lo que encuentres como clawdbot-*.service (o similar), detenlo + desactívalo:

# Ejemplo: si existe clawdbot-gateway.service
systemctl --user disable --now clawdbot-gateway.service

El disable es esencial para evitar que vuelva después de un reinicio.

3) Inicia el lado de OpenClaw

Una vez que el viejo se fue y 18789 está libre, inicia OpenClaw.

Iniciar vía systemd (servicio de usuario)

systemctl --user restart openclaw-gateway
systemctl --user status openclaw-gateway --no-pager

Iniciar manualmente para verificar

/home/mamu/.nvm/versions/node/v24.13.0/bin/node \
  /home/mamu/openclaw/dist/index.js gateway --port 18789

Finalmente, confirma que OpenClaw realmente tiene el puerto:

ss -ltnp | grep 18789

Lo que quieres ver es algo como users:(("node",pid=...)) — un proceso de OpenClaw que posee el puerto.

4) Para configuraciones SSH, abre el dashboard vía port forwarding

Usa ssh -N -L 18789:127.0.0.1:18789 mamu@192.168.0.108 como se describió arriba para configurar el túnel, luego abre http://localhost:18789/ en tu navegador.

Consejos rápidos

• OpenClaw no hizo nada mal: el fallo al iniciar fue solo “alguien más ya estaba sentado en el asiento 18789”
• kill es un parche temporal: la solución real es systemctl --user disable --now <servicio-viejo>
• La compilación de la UI (pnpm ui:build) es inofensiva: solo genera archivos estáticos, y es un tema aparte de lo que resolvimos aquí

Si quieres conservar el clawdbot viejo (coexistencia)

• Ejecuta OpenClaw en un puerto diferente (por ejemplo, 18889)
• La URL del dashboard cambia en consecuencia

# Ejemplo: iniciando OpenClaw en un puerto diferente
systemctl --user stop openclaw-gateway
openclaw configure --section gateway   # Cambia el puerto a 18889 aquí, o edita el archivo de configuración directamente
systemctl --user restart openclaw-gateway

Si ya no necesitas el clawdbot viejo (eliminación total)

• Desactiva todos los servicios de usuario de clawdbot
• Si es necesario, ten en cuenta que ~/.clawdbot es un symlink — ten cuidado de no eliminar accidentalmente ~/.openclaw al limpiar (esto es importante)

¿Es necesaria una compilación?

Puedes compilar cuando quieras — antes o después — pero el orden más seguro es:

1. Resuelve el conflicto de puertos primero (detén/desactiva clawdbot-gateway)
2. Inicia el gateway de OpenClaw y confirma que 18789 pertenece a OpenClaw
3. Luego, solo si se queja de que falta la UI, ejecuta pnpm ui:build (solo cuando sea necesario)

Compilar la UI absolutamente no va a arreglar el conflicto de puertos. Solo ejecuta cd ~/openclaw && pnpm ui:build cuando veas Control UI assets not found. Compilar antes no hace daño, pero no toca la causa raíz en absoluto.

Fase 5: Resolución a la mañana siguiente

Cuando revisé las cosas a la mañana siguiente, la conclusión fue: OpenClaw estaba funcionando perfectamente. Todos esos errores de “no arranca” y “el puerto está ocupado” del día anterior no eran bugs de OpenClaw — simplemente era cuestión de quién había tomado el puerto 18789 en ese momento.

Resultados de la verificación matutina

1) Qué está corriendo realmente

Una verificación con ps mostró que openclaw-gateway era el que estaba corriendo:

ps aux | egrep 'clawdbot|openclaw' | grep -v grep

mamu 2092 0.7 0.3 … openclaw-gateway (más otros procesos relacionados)

Así que OpenClaw en sí es el que tiene el puerto 18789 ahora.

2) Estado de systemd (servicios de usuario)

systemctl --user también muestra openclaw-gateway como running:

systemctl --user list-units --type=service --state=running | egrep 'clawdbot|openclaw'

openclaw-gateway.service loaded active running OpenClaw Gateway (v2026.2.4)

Aquí está la parte importante:

systemctl --user list-unit-files | egrep 'clawdbot|openclaw'

clawdbot-gateway.service enabled
openclaw-gateway.service enabled

La definición del servicio clawdbot-gateway sigue ahí (enabled). Pero el que realmente está corriendo es openclaw-gateway. En otras palabras, “no está causando problemas activamente ahora”, pero la mina sigue ahí (podría volver y causar un conflicto en el futuro).

Por qué “el inicio manual falla” (y por qué eso es perfectamente normal)

Ayer, clawdbot-gateway estaba ocupando 18789, así que OpenClaw no podía arrancar y daba errores. Pero hoy, después de reiniciar la PC, openclaw-gateway arrancó primero.

Si intentas esto en ese estado:

node ... dist/index.js gateway --port 18789

Por supuesto, como el gateway ya está corriendo, te sale:

• Inicio doble (gateway already running)
• Puerto en uso (Port 18789 is already in use)

Y se rechaza. Esto no es un problema — está funcionando correctamente.

En otras palabras, no es “no puede arrancar” — es “intentó arrancar pero fue detenido porque ya está corriendo”.

Apéndice: Desactiva la “mina” de clawdbot-gateway (opcional)

Ahora mismo openclaw-gateway tiene el puerto y todo está bien, pero hay una posibilidad de que clawdbot arranque de nuevo en el futuro y cause otro conflicto de puertos. Así que podría valer la pena cerrar así:

“Todo funciona ahora. Pero la unidad de clawdbot sigue habilitada, así que si quieres prevenir conflictos futuros, desactivarla es lo seguro”.

systemctl --user disable --now clawdbot-gateway.service
systemctl --user daemon-reload
systemctl --user reset-failed

Resumen

Solo ejecuta pnpm ui:build si te sale el error de assets de la UI. Después de un reinicio a la mañana siguiente, todo estaba funcionando. Ayer, clawdbot-gateway estaba ocupando el puerto 18789. Hoy, openclaw-gateway ya estaba corriendo, y el intento de inicio manual simplemente fue rechazado como un “inicio doble” — nada más.

Qué verificar a continuación (esta es la recta final)

Solo haz lo siguiente y listo.

¿Puedes abrir el dashboard?

Abre http://localhost:18789/ vía el port forward por SSH descrito arriba.

¿Y si te sale otro error de UI?

Si ves Control UI assets not found, ejecuta pnpm ui:build y reinicia el gateway (ver Fase 4). La pantalla carga, pero la Web UI no puede autenticarse contra el WebSocket del gateway. El error rojo en la captura es la clave:

unauthorized: gateway token missing (Open the dashboard URL and paste the token in Control UI settings)

Esto significa que el token falta o está mal, así que Health se queda atascado en Offline.

Fase 6: Configuración del CLI y autenticación

En resumen: todo lo que necesitas hacer es “pegar el token del Gateway en la UI”

OpenClaw usa autenticación por Token por defecto. Ese token debería estar en ~/.openclaw/openclaw.json en el lado del servidor.

1) Verifica el token en el lado del servidor (vía SSH)

cat ~/.openclaw/openclaw.json | sed -n 's/.*"token": *"\([^"]*\)".*/\1/p'

Si tienes jq instalado, esta es la opción más segura:

jq -r '.gateway.auth.token' ~/.openclaw/openclaw.json

Para más información sobre jq, consulta este artículo:

Un sitio cualquiera

Codex CLI: Accede a Conversaciones Pasadas desde Archivos JSONL ¿No puedes desplazarte en la TUI de Codex CLI? Aprende a leer el historial de conversaciones directamente desde archivos de registro JSONL, buscar sesiones pasa…

La cadena que obtienes aquí es el token que necesitas pegar en la Control UI.

2) En el lado del navegador

• Pégalo en el campo Gateway Token
• Haz clic en Connect — si el mensaje rojo de token missing desaparece, todo está bien.

Si sigue sin funcionar después de pegar (errores comunes)

A) “token missing” se convierte en “token invalid / unauthorized”

Esto probablemente significa que estás viendo el token equivocado (quizás de un proceso o archivo de configuración diferente). Para verificar:

systemctl --user status openclaw-gateway --no-pager -l
cat ~/.openclaw/openclaw.json | head

B) No hay ningún token en el archivo

Haz lo que dice el recuadro rojo en la UI — genera uno y pégalo. El comando que muestra ese recuadro rojo es: openclaw doctor --generate-gateway-token. Si estás ejecutando las cosas a través de pnpm:

pnpm openclaw doctor --generate-gateway-token

Pega el token generado en la UI y haz clic en Connect.

¿Qué pasa con “Password (not stored)”?

Como estamos usando autenticación por Token, básicamente no lo necesitas. Déjalo vacío a menos que hayas cambiado explícitamente a autenticación por contraseña.

Qué es realmente “Password (not stored)”

Esta es una ruta de autenticación alternativa para conectarse desde la Control UI (navegador) al Gateway. Dependiendo de la configuración, algunos entornos usan un enfoque de “contraseña compartida” — eso es todo.

• Método por Token (gateway token) — Es lo que estamos usando ahora. Ingresa el Gateway Token en la Control UI y estás conectado. Deja el campo de contraseña vacío.
• Si cambiaste a modo de contraseña (configurado explícitamente) — El sistema pedirá una contraseña en lugar de un Token. Solo entonces usas este campo.

Y como dice la UI con (not stored), la contraseña no se guarda en el lado del navegador, así que probablemente te la pida cada vez. Por eso los tokens son simplemente más fáciles.

Mejor práctica para esta configuración

• El Gateway corre como daemon vía systemd (openclaw-gateway.service)
• La Control UI solo necesita el Gateway Token
• No toques el campo de contraseña (déjalo vacío)

Si ves Health OK / Connected, terminaste.

Hasta este punto, el Gateway en sí estaba funcionando bien, pero estaba confundido porque no podía ejecutar openclaw en la terminal. La razón era muy simple — el Gateway se inició vía systemd, pero en realidad no había instalado el CLI (el comando openclaw) todavía. La solución es ejecutar npm install -g . (instalar desde el repo) para habilitar el comando openclaw, luego conectarse con openclaw tui. Si tienes autenticación por token habilitada, conéctate explícitamente así: openclaw tui --url ws://127.0.0.1:18789 --token <token>.

A) Instalar el repo actual (~/openclaw) globalmente “tal cual” como CLI (recomendado)

Este enfoque toma lo que ya compilaste y lo convierte en el comando openclaw.

cd ~/openclaw
npm install -g .
hash -r
command -v openclaw
openclaw --version

mamu@evo-x2:~/openclaw$ npm install -g .

added 1 package in 245ms
mamu@evo-x2:~/openclaw$ hash -r
mamu@evo-x2:~/openclaw$ command -v openclaw
/home/mamu/.nvm/versions/node/v24.13.0/bin/openclaw
mamu@evo-x2:~/openclaw$ openclaw --version
2026.2.4

B) Instalar el paquete openclaw publicado desde npm

El enfoque de “simplemente instalar la versión distribuida”.

npm install -g openclaw
hash -r
command -v openclaw
openclaw --version

Si command -v openclaw muestra una ruta, ganaste. (Las instrucciones de macOS también asumen que instalas vía npm install -g openclaw@..., así que filosóficamente, esta es la manera “correcta”.)

Lo primero: una verificación rápida (recomendado)

1) Asegúrate de que está vivo

openclaw --help

Si obtienes una lista de subcomandos, es prueba de que el CLI está instalado correctamente.

2) ¿Puede conectarse al Gateway? (esta es la importante)

openclaw tui

En este punto, la situación es básicamente “el Gateway (el recipiente) está corriendo, pero el ‘cerebro’ (el modelo) no tiene auth configurado, así que el TUI se queda esperando una respuesta”. De hecho, durante el onboarding, probablemente viste esto:

• No auth configured for provider "anthropic". The agent may fail until credentials are added. — Eso es exactamente lo que se muestra como “pondering…” en el TUI.

Y según la especificación del asistente de OpenClaw, Anthropic soporta no solo claves de API sino también “Claude Code OAuth” y “pegar un setup-token” como métodos de autenticación.

En resumen: ¿éxito? El Gateway está bien. El LLM todavía no está.

Así están las cosas:

• openclaw-gateway.service: active (running)
• Luego token_missing se convirtió en webchat connected (porque pegamos el token)

Así que la configuración del Gateway es un éxito. Sin embargo, la autenticación de Anthropic (para realmente usar Claude como LLM) es un asunto completamente separado, y esa parte aún no está lista.

Por qué el TUI no responde ahora mismo

Escribiste algo como:

“Dime el nombre del modelo que estás usando actualmente”

en el TUI, y ha estado “pensando” por 2-3 minutos. Generalmente es una de estas:

1. No hay auth de Anthropic configurado (lo más probable)
2. El modelo predeterminado sigue siendo Anthropic, pero no hay auth para él
3. La resolución del modelo falló por completo (atascado en “unknown”)

La especificación del asistente incluso menciona “mostrar una advertencia de ‘auth faltante’ durante la verificación del modelo” — eso es justo lo que está pasando en la vida real.

¿Cómo lo arreglamos? (la ruta más rápida por terminal)

El objetivo aquí es “quiero usar Auth (la autenticación de Claude Code) en lugar de una clave de API”, así que esto es lo que necesitas hacer.

A) Reutilizar las credenciales OAuth de Claude Code (recomendado)

Según el asistente, en Linux/Windows, OpenClaw puede reutilizar ~/.claude/.credentials.json.

Entonces:

1. Asegúrate de que Claude Code ya tenga sesión iniciada en esta máquina
2. Luego configura OpenClaw para usar Anthropic OAuth

El comando exacto varía según el entorno, así que lo más seguro es usar el flujo integrado de OpenClaw:

• openclaw configure (interactivo — te permite configurar Models/Auth)
• Si puedes especificar una sección: openclaw configure --section models / --section auth

Este punto de entrada “configure” existe oficialmente, como se mostró en la pantalla de onboarding (“puedes cambiar esto después con openclaw configure“).

B) El método setup-token (confiable incluso por SSH)

Este es el enfoque descrito en la especificación del asistente:

• Ejecuta claude setup-token en alguna terminal
• Pega el token que aparece (el nombre puede dejarse en blanco)

Esto crea una ruta donde Anthropic funciona sin una clave de API.

Al ejecutar openclaw configure:

◇  Existing config detected ─────────╮ │ │  workspace: ~/.openclaw/workspace │ │  gateway.mode: local │ │  gateway.port: 18789 │ │  gateway.bind: loopback │ ├────────────────────────────────────╯ │ ◆  Where will the Gateway run? │  ● Local (this machine) (Gateway reachable (ws://127.0.0.1:18789)) │  ○ Remote (info-only)

Esta pantalla significa que estás exitosamente en la UI de configuración — tanto el CLI como el Gateway son visibles. Que aparezca Gateway reachable (ws://127.0.0.1:18789) confirma la conectividad.

Elige Local y presiona Enter (Remote es solo para “conectarse a un Gateway en un host diferente”).

Selecciona la sección Model, luego Anthropic, luego Anthropic token (paste setup-token):

◇  Anthropic auth method │  ● Anthropic token (paste setup-token) (run `claude setup-token` elsewhere, then paste the token here) │  ○ Anthropic API key │  ○ Back

Esta es exactamente la ruta de “usar Auth en lugar de una clave de API”.

Esto es lo que debes hacer

1. En una terminal separada (o en tu PC local):

claude setup-token

2. Copia el setup-token generado
3. Pégalo en la pantalla actual en Anthropic token (paste setup-token) y continúa

¿Dónde ejecutas claude setup-token?

• Por SSH está bien (siempre y cuando el comando claude esté instalado en el destino SSH)
• Si el destino SSH no tiene claude / no tiene sesión iniciada:
  • Ejecuta claude setup-token en tu máquina local (lado Windows) → solo pega el token en OpenClaw del lado SSH — eso también funciona

¿Necesitas ANTHROPIC_API_KEY para esto?

No. (Solo lo necesitarías si seleccionas “Anthropic API key”)

OpenClaw puede usar Anthropic mediante una clave de API, pero en este caso simplemente pegamos un setup-token de Claude Code y funcionó para la autenticación.

En este caso, el setup-token se generó en Windows PowerShell, que activó la autenticación por navegador, y el token apareció en PowerShell.

◇  Paste Anthropic setup-token │  sk-ant-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx │ ◆  Token name (blank = default) │  default

El Token name (blank = default) es solo una “etiqueta” para guardar el token del lado de OpenClaw.

• Si tienes dudas, simplemente presiona Enter dejándolo en blanco (= usa “default”)
• Si quieres gestionar múltiples tokens (trabajo/personal/pruebas), dale un nombre reconocible como anthropic-win o claude-code

De cualquier forma, prácticamente no tiene impacto en la funcionalidad (es solo una etiqueta de gestión para “qué token referenciar”).

Luego selecciona anthropic/claude-opus-4-6 de la lista de modelos y completa la configuración:

◇  Anthropic OAuth models │  anthropic/claude-opus-4-6 Updated ~/.openclaw/openclaw.json │ ◆  Select sections to configure │  ○ Continue

Selecciona Continue para terminar el asistente de configuración:

◇  Select sections to configure │  Continue Missing Control UI assets. Build them with `pnpm ui:build` (auto-installs UI deps). │ ◇  Control UI ────────────────────────────────────────╮ │ │  Web UI: http://127.0.0.1:18789/ │ │  Gateway WS: ws://127.0.0.1:18789 │ │  Gateway: reachable │ ├─────────────────────────────────────────────────╯ │ └  Configure complete.

¡Configuración completa! El mensaje “Missing Control UI assets” es un error desde la perspectiva de la UI (el navegador no puede mostrar nada), pero simplemente significa que los archivos estáticos de la Control UI (dist/control-ui) no se han compilado todavía.

Entonces, en resumen:

• Si ves este mensaje en el navegador → pnpm ui:build es necesario
• Si ya ejecutaste pnpm ui:build y todavía lo ves → la salida de la compilación está en la ubicación equivocada / el gateway está buscando en una ruta antigua / los archivos se eliminaron

Fase 7: Verificación y toques finales

El camino más corto para “listo” (esto cubre el 90%)

cd ~/openclaw
pnpm ui:build
systemctl --user restart openclaw-gateway

Luego haz una recarga forzada (los assets en caché adoran quedarse pegados):

• En un navegador de Windows: Ctrl + F5 (o Ctrl+Shift+R)

Si todavía ves “Missing assets” (puedes diagnosticarlo en 1 minuto)

1) ¿Realmente existen los archivos compilados?

ls -la ~/openclaw/dist/control-ui/ | head

Si ves index.html y assets/, la salida de la compilación está bien.

2) ¿El Gateway realmente está buscando esos archivos? (revisa los logs)

journalctl --user -u openclaw-gateway -n 80 -o cat --no-pager

Si Control UI assets not found todavía aparece aquí, probablemente la ruta de referencia está mal.

¿Por qué surge lo de “puede que no sea realmente un error”?

El mensaje del CLI openclaw configure “Missing Control UI assets …” a veces se muestra como una advertencia que significa “la UI es opcional — el Gateway funciona bien sin ella”. Pero en nuestro caso, el navegador no muestra nada más que ese mensaje = es fatal desde la perspectiva de la UI, así que desde el punto de vista de la experiencia del usuario, absolutamente es un error.

Aunque el Gateway en sí esté corriendo, la Control UI es algo separado. Si los archivos estáticos de la UI no se han compilado, el navegador se detiene en “Missing assets”. Solución: pnpm ui:build y luego reiniciar el Gateway.

A continuación: comandos de gestión tipo “admin”

OpenClaw se divide en el “Gateway (siempre corriendo)” y el “CLI/TUI (la interfaz del operador)”. Empecemos probando que las cosas realmente están corriendo detrás de escena.

3) Estado del Gateway (visto desde el lado del CLI)

openclaw gateway status

4) Limpieza de procesos duplicados o algo raro

openclaw gateway stop

Importante: si ves “assets not found” en la Control UI

Como se mencionó arriba, pnpm ui:build seguido de un reinicio del Gateway lo arregla. Si ya compilaste, no necesitas hacerlo de nuevo. “Si la UI abre, ganaste”.

¿Listo para configurar cosas? (próximos pasos)

5) Recorre la configuración interactiva (modelo/auth/búsqueda web, etc.)

openclaw configure

Aquí es donde configuramos Anthropic usando el “setup-token (método Auth)”. El punto clave es que en lugar de pegar directamente una clave de API, pasas por la autenticación del navegador y pegas un token. (El flujo: ejecuta claude setup-token en Windows PowerShell, autentícate en el navegador, obtén un token, pégalo en el lado Linux.)

¿Quieres ver el archivo de configuración?

6) Verifica tu configuración actual al instante

cat ~/.openclaw/openclaw.json

Si anthropic/claude-opus-4-6 aparece ahí, la configuración de “Claude es el cerebro” está completa.

Orden recomendado (cuando tengas dudas, sigue este)

1. openclaw tui (el evento principal: ¿realmente puedes tener una conversación?)
2. openclaw gateway status (prueba de que las cosas están corriendo en segundo plano)
3. openclaw configure (preparar el terreno para después: modelo/auth/herramientas)
4. cat ~/.openclaw/openclaw.json (ver la configuración real)

Missing Control UI assets... no es “fallo de configuración” — solo significa “la UI no se ha compilado todavía” (ver Fase 4).

Ahora vamos a reintentar la verificación rápida que falló antes:

openclaw tui

Una vez que lance el TUI, escribe:

Dime el nombre del modelo que estás usando actualmente

Y deberías recibir:

Estoy usando anthropic/claude-opus-4-6.

Si la barra de estado en la parte inferior también muestra anthropic/claude-opus-4-6, eso es prueba de que toda la cadena — OpenClaw, Gateway y Claude (Auth) — está completamente conectada.

Qué hacer a continuación (orden recomendado)

1. openclaw gateway status — Prueba de que el Gateway está corriendo en segundo plano
2. cat ~/.openclaw/openclaw.json — Muestra la configuración real
3. La advertencia de assets de la Control UI no importa si el TUI funciona. Solo ejecuta pnpm ui:build y reinicia el Gateway si quieres una experiencia más agradable en el lado del navegador.

¿Cambia el consumo de tokens?

La respuesta corta: es básicamente Claude el que consume los tokens. OpenClaw en sí no aumenta mágicamente el uso de tokens — depende de qué y cuánto le envíes a Claude. Dicho esto, tener a OpenClaw en el medio sí introduce factores que pueden empujar el consumo hacia arriba o hacia abajo.

Patrones que aumentan el uso (a menudo causados por OpenClaw)

• Mantener historiales de sesión largos y enviarlos todos de una vez cada vez
• Pasar la salida cruda de herramientas (logs largos/JSON/HTML) directamente al LLM
• Usar modelos pesados de “modo pensamiento/razonamiento” donde el razonamiento interno va profundo
• Apilar “instrucciones del sistema + descripciones de skills + info del entorno” en el prompt

En otras palabras, no es “porque OpenClaw está corriendo” — es que tus patrones de uso de OpenClaw determinan cuánta información se envía al LLM.

Patrones que reducen el uso (cuando OpenClaw funciona bien)

• OpenClaw resume el historial antes de enviarlo
• Los resultados de herramientas se recortan a solo las partes relevantes antes de enviarlos
• Las sesiones se dividen por propósito para mantener el contexto limpio

Donde podrías “sentir una diferencia” en el consumo

Aunque estés usando el mismo Claude por debajo:

• Claude Code (el comando claude) tiene un “estilo orientado al desarrollo” (muchas referencias a archivos y llamadas a herramientas)
• OpenClaw tiene un “estilo orientado a agentes” (sesiones/herramientas/canales/skills)

La forma en que envían las cosas es diferente, así que los patrones de uso de tokens también serán diferentes.

Algo que puedes verificar ahora mismo

En openclaw tui, deberías ver algo como:

tokens 0/200k

Este número sube conforme sigues chateando. Aumenta no “porque OpenClaw está corriendo”, sino porque la entrada enviada a Claude + la salida que Claude devuelve sigue acumulándose.

OpenClaw es el “recipiente (manos y pies)”, Claude es el “cerebro”. Lo que determina el costo (tokens) es cuánta información OpenClaw le pasa a Claude.