OpenCode 2.0, la nueva versión del agente de programación de código abierto desarrollado por Anomaly, ya no vive en la terminal: se ejecuta como un servicio en segundo plano, en el puerto 49374 en macOS, Linux y WSL, al que se conectan la terminal, la web, la app de escritorio y los scripts. El ingeniero Najam Us Saqib ha comprobado en un artículo publicado en Towards AI que ese cambio deja fuera de juego muchos de los entornos aislados (sandbox) que los equipos montaron alrededor de la versión 1.x.
Las claves de OpenCode 2.0 y el riesgo para los sandbox de agentes en 30 segundos
- OpenCode 2.0 convierte el agente en un servicio compartido que escucha solo en localhost, en el puerto 49374 (45278 en Windows).
- El comando que se lanza ahora es un cliente: las herramientas del agente se ejecutan en el servicio.
- En una prueba, un cliente dentro de un sandbox de solo lectura creó un archivo en el equipo anfitrión a través de la API.
- La opción –standalone o un servicio propio por sandbox evitan el problema.
Según el anuncio de Anomaly del 12 de octubre, la versión 2.0 traslada el agente a «un único proceso en segundo plano» en la máquina del usuario, reconstruye desde cero su API y permite plugins que se recargan en caliente, hasta el punto de que el agente puede escribirse uno a mitad de sesión y usarlo enseguida. La compañía asegura que OpenCode tiene millones de usuarios diarios, una cifra que no detalla. Para Saqib, que reconoce usar a diario Claude Code y no OpenCode, el diseño es mejor ingeniería, pero mueve la frontera de seguridad.
El sandbox rodea al proceso equivocado
En OpenCode 1.x el servidor era opcional. Cuando un investigador informó a principios de 2026 de un fallo de inyección de comandos en ese modo, los mantenedores respondieron que el modo servidor era opcional y que protegerlo correspondía al usuario. Muchos equipos optaron entonces por envolver el comando opencode en un sandbox, ya fuera con Landlock en Linux, un contenedor o herramientas como Fence, porque las herramientas del agente corrían dentro de ese proceso.
En la 2.0 el comando que se lanza es un cliente que se conecta al servicio compartido, y es ahí donde se ejecutan las sesiones y las herramientas. El envoltorio de sandbox de TNG ya se topó con ello: su sandbox de Linux solo permite puertos concedidos de forma explícita, así que el cliente no podía llegar al servicio. La incidencia descarta conceder el puerto 49374 como solución, porque el cliente se conectaría al servicio del anfitrión y ejecutaría las herramientas fuera del sandbox. TNG optó por dar a cada lanzamiento aislado su propio servicio privado, en otro puerto de loopback y con su propio directorio de configuración.
Saqib reprodujo la situación con OpenCode 2.0.29 en un contenedor Linux desechable, sin conectar ningún modelo. Dentro de un sandbox de bubblewrap con todo el sistema de archivos en solo lectura, touch fallaba como debía; pero una llamada a la API del servicio desde ese mismo sandbox creó el archivo en el proyecto del anfitrión. No hubo exploit: el cliente encontró el servicio, leyó la contraseña de los archivos de OpenCode del usuario e hizo una llamada normal. La CLI incluye la opción --standalone, que arranca un servidor privado en lugar de usar el servicio común, y en su prueba levantó su propio servidor en un puerto aleatorio.
Acceso remoto, plugins y valores por defecto
Según la documentación de la versión 2 que cita el autor, el servicio solo escucha en localhost por defecto. El comando opencode pair conecta otras apps y navegadores con enlaces de un solo uso que caducan a los cinco minutos, y una sesión emparejada dura 30 días. opencode pair --remote expone el servicio mediante un túnel cifrado de extremo a extremo que sigue exigiendo la contraseña del servidor. La primera vez se muestra un aviso de que el servidor quedará expuesto a Internet, y en un script sin terminal hace falta --yes; una vez aceptado, las siguientes ejecuciones ya no preguntan, aunque se haya desactivado el acceso remoto. También se puede escuchar en todas las interfaces con opencode service set hostname 0.0.0.0.
El punto que Saqib vigilaría más de cerca son los plugins: se ejecutan dentro del servicio con sus permisos, y el agente puede escribir uno y cargarlo en la misma sesión. Un comentarista de Hacker News lo calificó de desajuste de seguridad; el autor no llega tan lejos, pero cree que el directorio de plugins merece la misma revisión que cualquier código que llegue a producción. La versión 1.19.0, la que invita a pasar a la 2.0 con opencode upgrade --major, ya no instala actualizaciones de forma automática y valida el origen de las conexiones de terminal. Además, como recuerda Capital and Compute, la 2.0 cambia la API de plugins, la del servidor y la configuración de terminal, y deja de ejecutar servidores de lenguaje (LSP).
Seis comprobaciones para los equipos que lo usan
El propio autor reconoce que los valores por defecto son razonables: el servicio rechazó su petición sin autenticar, la contraseña generada está en archivos que solo puede leer el usuario y el modelo se parece al que llevan años usando VS Code Server o Jupyter. Su recomendación es revisar dónde quedó el aislamiento:
- Ejecutar
opencode service statusen cada equipo actualizado y confirmar que escucha en 127.0.0.1 y no en 0.0.0.0. - No conceder el puerto 49374 al sandbox ni montar en él la configuración de OpenCode; usar
--standaloneo un servicio por sandbox. - Buscar
pair --remotey--yesen scripts y dotfiles, porque la aceptación es permanente. - Cambiar la contraseña con
opencode service set password, lo que cierra todas las sesiones emparejadas. - Poner el directorio de plugins bajo control de versiones o monitorización de archivos.
- Fijar la versión en los equipos y planificar
opencode upgrade --major, porque los plugins de la 1.x no funcionan en la 2.0.
El aislamiento de agentes con permisos limitados es una tendencia que noticias.ai ya ha recogido en proyectos como maat, el agente para Ubuntu que no puede cambiar nada por su cuenta. En el caso de OpenCode 2.0, la conclusión de Saqib es sencilla: un sandbox solo protege el proceso que envuelve, y ahora ese proceso ya no es la terminal.
Preguntas frecuentes
¿OpenCode 2.0 queda expuesto a la red por defecto?
No. Según la documentación, el servicio solo escucha en localhost salvo que se cambie el hostname o se active el acceso remoto.
¿Qué puerto usa OpenCode 2.0?
El 49374 en macOS, Linux y WSL, y el 45278 en Windows.
¿Sigue funcionando un sandbox montado para OpenCode 1.x?
Solo si las herramientas se ejecutan dentro de él. En la prueba de Najam Us Saqib, un cliente en un sandbox de solo lectura creó un archivo en el anfitrión a través del servicio compartido.
¿Cómo se aísla correctamente OpenCode 2.0?
Ejecutando el agente con –standalone dentro del sandbox o dando a cada sandbox su propio servicio y directorio de configuración, como hizo TNG.
Fuentes:
