OpenCode Web en el navegador: configura el puerto y protege el acceso

OpenCode Web es una interfaz de navegador para el servidor de OpenCode. Sirve para ver sesiones, abrir un proyecto en una pestaña o mantener una segunda vista sin trabajar todo el tiempo en la TUI. Sigue siendo un servicio de desarrollo local; no es una cuenta alojada que gestione tus credenciales de proveedor.

El primer comando debe ser opencode web sin cambiar el hostname. La documentación oficial indica que el servidor usa 127.0.0.1, elige un puerto disponible y abre el navegador predeterminado. Con ese límite local puedes comprobar carpeta, proveedor, permisos y sesiones antes de exponer nada.

Solo después elige un puerto fijo, un hostname de red, mDNS o CORS. Cada opción cambia quién puede conectar. Un navegador que no carga suele señalar proceso o puerto; un servidor visible para personas equivocadas es un problema de límite y requiere reducir la exposición.

opencode web

Ejecuta el comando desde el repositorio que quieres usar. OpenCode inicia el servidor Web y abre el navegador. Mantén visible la terminal que posee el proceso para anotar dirección, puerto y avisos. Que una pestaña cargue no demuestra que el proceso vea los archivos correctos o alcance el modelo elegido.

Para una configuración repetible usa opencode web --port 4096. Un puerto fijo facilita marcadores, scripts y opencode attach, pero puede chocar con otro proceso. Si falla, identifica primero quién ocupa el puerto; no publiques todos los puertos del equipo como solución.

La primera tarea Web debe ser de solo lectura: listar el proyecto, resumir un archivo pequeño y revisar la sesión o el estado del servidor. Después comprueba Git status y el modelo desde el mismo workspace. Así separas navegador, proceso, repositorio y proveedor.

El puerto es un número del host; el hostname define qué interfaces aceptan conexiones. El valor 127.0.0.1 es local. --port 4096 cambia el número, mientras que --hostname 0.0.0.0 cambia la exposición y permite que otros equipos intenten conectar.

mDNS resulta cómodo en una red local de confianza. El ejemplo oficial usa opencode web --mdns y anuncia opencode.local; --mdns-domain separa varias instancias. Descubrir un servicio no cifra el tráfico ni sustituye la autenticación.

CORS controla qué orígenes del navegador pueden hacer peticiones entre dominios. Puede ser necesario para un frontend propio, pero no vuelve privado un servidor expuesto. Mantén una lista exacta y prueba el Origin real, no una regla comodín.

La advertencia oficial es clara: sin OPENCODE_SERVER_PASSWORD el servidor queda sin protección. Puede valer para una prueba solo local, pero no cuando otro dispositivo puede conectarse. Inyecta la contraseña al iniciar y no la guardes en opencode.json, historial, capturas ni .env versionados.

El usuario predeterminado es opencode y OPENCODE_SERVER_USERNAME permite cambiarlo. Estas credenciales protegen el servidor Web, no el proveedor ni el repositorio. Revisa por separado las claves, permisos, montajes y el usuario que ejecuta el proceso.

Antes de usar --hostname 0.0.0.0, revisa firewall y segmento de red. Prefiere una red privada, una contraseña temporal y un puerto conocido. Si hay proxy, VPN o frontend, documenta dónde termina TLS y qué capa sigue viendo la sesión.

La página inicial Web muestra sesiones activas y permite crear otras. Confirma el proyecto antes de enviar una petición. Una pestaña puede sobrevivir a un cambio de proceso o repositorio, así que vuelve a comprobar el estado del servidor en vez de confiar en una pestaña antigua.

El estado del servidor ayuda a distinguir el proceso Web de una sesión conectada. Si falta el modelo, revisa proveedor e ID; si faltan archivos, revisa directorio de trabajo y usuario del proceso antes de cambiar el prompt o reinstalar.

Para usar ambas interfaces inicia el servidor y ejecuta opencode attach http://localhost:4096 en otra terminal. La documentación oficial describe sesiones y estado compartidos. Mantén un solo responsable de escritura y revisa el diff tras cada cambio pequeño.

La página oficial recomienda ejecutar opencode web desde WSL en Windows para mejorar la integración de archivos y terminal. Es relevante si el repositorio está en una ruta Linux, las herramientas viven en WSL o PowerShell usa otro PATH y home.

Anota dónde se ejecuta el comando, dónde está el repositorio y qué usuario posee el proceso. Un navegador de Windows puede conectar con WSL, pero localhost, firewall y rutas pueden cruzar límites que la terminal no muestra. Prueba solo lectura antes de editar.

Si la página carga pero fallan comandos o referencias, compara opencode --version, carpeta actual, variables del proveedor y el shell que inició Web. Las guías de despliegue, VS Code y permisos cubren las capas cercanas; esta página se centra en el servidor del navegador.

Empieza por proceso y URL y avanza hacia dentro. Un error de conexión apunta a proceso, puerto, hostname, firewall o CORS. Una página que carga pero no crea sesión apunta a proyecto, proveedor, permisos o modelo. Cambiar todo a la vez elimina la evidencia.

Con un puerto fijo comprueba quién escucha y que la URL impresa use el mismo número. Con un hostname de red prueba primero localhost y la contraseña, después el segundo equipo. Con mDNS compara el nombre anunciado con la dirección real.

Si una sesión se comporta raro, guarda comando, directorio, ID de modelo, origen de variables y Git status. Reproduce una petición corta de solo lectura y luego un cambio pequeño. Detente si el diff contiene secretos, archivos ajenos o rutas fuera del worktree.

Usa Web cuando el navegador facilite revisar proyecto y conversación, cuando necesites otra vista del servidor o cuando el equipo quiera una URL local repetible. La TUI sigue siendo mejor para navegación por teclado, trabajo intenso de shell o entornos sin navegador.

Web no sustituye las guías de proveedor, permisos o Docker: solo cambia cómo llegas al servidor. Credenciales, permisos, montajes, herramientas MCP y revisión Git conservan sus propias comprobaciones. Enlaza la guía concreta para no duplicar todas las reglas aquí.

Una rutina estable es: iniciar en local, validar proyecto y modelo, poner contraseña antes de ampliar hostname, registrar el puerto, conectar TUI solo cuando haga falta y cerrar el servidor al terminar. Así conservas la comodidad sin convertir un listener de desarrollo en un servicio público.