Deja que OpenCode corrija el fallo mientras tú sigues en tu árbol de trabajo

Tienes un cambio a medio escribir cuando alguien informa de un fallo en el analizador de fechas. Quieres seguir editando tus archivos y asignar al agente de programación una tarea aparte. En cuanto ambos editáis el mismo directorio, hasta una corrección pequeña cuesta de separar de tu trabajo en curso.

El 6 de noviembre, OpenCode 2.2.6 añadió una opción de árbol de trabajo a las ejecuciones desde scripts en la línea de comandos. OpenCode es un agente de programación de código abierto con una interfaz interactiva de terminal y un comando específico para ejecutar una petición desde un script. La nueva opción permite iniciar OpenCode en otro árbol de trabajo de Git, darle un nombre si quieres y dejar libre el directorio original. La misma versión añadió la posibilidad de compartir, de forma optativa, conexiones coincidentes del protocolo MCP (Model Context Protocol). La combinación plantea dos preguntas antes de empezar. ¿Qué archivos puede cambiar el agente y qué servicios puede usar? Versión 2.2.6 de OpenCode · Documentación de la línea de comandos de OpenCode

Una buena configuración reúne una tarea acotada, un punto de partida previsible, un lugar para revisar los cambios y permisos explícitos para todo lo que sale del proyecto.

Captura del proyecto OpenCode que muestra un parche y una sesión. El recurso de marca de la versión ilustra la interfaz de terminal. La imagen va acompañada del aviso de licencia MIT. Telli.sh ajustó el tamaño de la captura y añadió márgenes.

Un directorio independiente permite revisar los cambios con confianza

Un árbol de trabajo de Git da a cada tarea sus propios archivos e índice. Ilustración original de Telli.sh.

Los árboles de trabajo de Git vinculan varios directorios a un repositorio. Cada árbol tiene sus propios archivos, índice y posición actual en el historial. Comparten la mayor parte de los datos del repositorio. Un árbol separado permite examinar el parche del agente mientras tus cambios originales siguen donde los dejaste. También cambia el código que ve el agente. Los cambios sin confirmar del primer directorio no aparecen en el segundo solo porque ambos pertenecen al mismo repositorio. Documentación de Git worktree

La versión de OpenCode del 6 de noviembre documenta tres formas de activar este comportamiento. Usa opencode run -w o opencode run --worktree para crear un árbol nuevo y --worktree=<name> si quieres darle nombre. La versión especifica que la opción no se puede combinar con --continue ni con --session. Una ejecución nueva necesita un contexto de partida propio. Si el informe de error ya incluye una conversación larga, lleva los pasos de reproducción pertinentes y el resultado esperado a la nueva petición. Versión 2.2.6 de OpenCode · Implementación y ejemplos de worktree

Usa el directorio separado como lugar de revisión. Antes de empezar, apunta la rama y el commit que esperas que use el agente. Después, comprueba el commit y el estado del árbol resultante. Si una prueba depende de un dato sin seguimiento o de un cambio que solo existe en el editor del desarrollador, esa diferencia en el punto de partida explica resultados aparentemente contradictorios. Un parche puede ser correcto en una versión anterior y aun así resultar inadecuado para la rama que vas a publicar.

Prueba con un cambio pequeño antes de delegar uno mayor

Empieza en un repositorio que controles y con una tarea concreta. Una prueba fallida sobre el día bisiesto es mejor primer experimento que una actualización amplia porque el resultado esperado es fácil de verificar. Otro caso acotado es corregir un enlace de navegación obsoleto con una sola prueba de ruta. En ambos casos, describe expresamente qué comportamiento debe cambiar y cómo lo comprobarás.

1. Registra el estado inicial. En el directorio actual, usa git status --short y git rev-parse HEAD. Guarda la salida junto con el informe del fallo. Si ya tienes una referencia que supera las pruebas, apunta cómo reproducirla. Usa opencode --version para confirmar que tu versión incluye la opción nueva. Versión 2.2.6 de OpenCode

2. Da al agente una sola tarea con un árbol de trabajo identificado. Incluye la reproducción y la prueba objetivo en la petición. El ejemplo usa un analizador de fechas ficticio y supone que el repositorio ya tiene una prueba específica. Pedir que deje los cambios sin confirmar facilita la inspección. Define límites más firmes en los permisos y el entorno de ejecución.

   ShellEjecutar en Terminal

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. Localiza el directorio nuevo antes de examinar el resultado. Ejecuta git worktree list desde el repositorio original y usa la ruta indicada. En el directorio nuevo, comprueba git status --short, git diff y git diff --cached. El último importa si el agente añadió cambios al índice. Revisa por separado los archivos sin seguimiento. Vuelve a ejecutar las pruebas específicas desde el directorio del agente y verifica que cubran tanto el 29 de febrero de un año bisiesto como un año en que esa fecha no existe. Documentación de Git worktree

4. Integra solo lo que hayas revisado. Mantén separado el cambio propuesto hasta poder aplicar un commit o un parche revisado a la rama prevista. Vuelve a consultar el estado del directorio original. Conserva el árbol del agente hasta que hayas registrado lo que te haga falta y comprobado que no contiene cambios pendientes que quieras mantener. La lista de árboles de Git facilita saber qué directorio corresponde a cada tarea. Documentación de Git worktree

El patrón también sirve si llegan dos problemas independientes a la vez. Da a cada uno un alcance reducido y compara las dos diferencias antes de integrarlas. La separación impedirá que un cambio de pruebas sin preparar del primer agente aparezca en el directorio del segundo. Las correcciones aún pueden entrar en conflicto al llegar a la misma rama, sobre todo si tocan una función compartida. La integración y las pruebas finales de regresión siguen perteneciendo al proceso habitual de revisión.

Decide qué puede hacer cada parte fuera del repositorio

Dos árboles pueden ejecutarse con la misma cuenta del sistema operativo. Pueden compartir variables de entorno, asistentes de credenciales y red. La nueva opción elige dónde empieza la ejecución y separa los cambios cotidianos. Si necesitas límites más estrictos, establece restricciones distintas de cuenta o de entorno. Una solicitud de permiso controla las herramientas que la respetan. El sistema operativo o el entorno de ejecución determinan hasta dónde puede llegar el proceso.

La ubicación de los cambios, la aprobación de herramientas y el acceso en ejecución son controles distintos. Ilustración original de Telli.sh.

La documentación de permisos de OpenCode V2 describe reglas ordenadas para acciones individuales. Entre los efectos están allow, ask y deny, con prioridad para la última regla que coincide. Un ejemplo oficial pide confirmación para órdenes de terminal, permite los comandos habituales de inspección y deniega los envíos al remoto. Si prevés ejecutar el trabajo sin nadie que pueda aprobarlo, prueba el comportamiento de una regla ask antes de incorporarla a una tarea periódica. Define prohibiciones claras en la configuración y usa credenciales de corta duración y alcance reducido para los servicios que el trabajo necesite. Documentación de permisos de OpenCode

Una tarea de documentación permite probar estas capas con sencillez. Autoriza al agente a cambiar una sección en un proyecto de ejemplo. Dale un proveedor cuyo uso esté autorizado y prescinde de credenciales de producción. Ejecuta el script y comprueba que el parche toca solo el archivo esperado. Si más adelante la automatización necesita un remoto o una herramienta de incidencias, justifica cada acceso y verifica sus permisos por separado.

Compartir una conexión tiene sentido cuando los proyectos comparten el mismo ámbito

MCP permite al agente usar herramientas de otros programas, como un buscador de documentación o un gestor de incidencias. En la versión del 6 de noviembre, pool: true permite a los directorios atendidos por un mismo servidor de OpenCode reutilizar una conexión cuando coincide la configuración pertinente. La documentación oficial de V2 indica que esta agrupación se aplica a la revisión del protocolo 2026-07-28. Si un servidor negocia una revisión anterior, mantiene conexiones separadas. La coincidencia exige más que apuntar los proyectos a la misma dirección. Deben coincidir la configuración remota y las cuentas autenticadas. En un servidor local cuentan también el comando, el entorno y el directorio de trabajo. Versión 2.2.6 de OpenCode · Documentación de conexiones MCP compartidas

Imagina dos árboles que consultan el mismo servicio interno de documentación con la misma cuenta. Compartir puede reducir la creación de conexiones duplicadas si el servicio admite la revisión pertinente. Confirma primero que ambos directorios deban acceder al mismo material y que la integración solo ofrezca las funciones necesarias. Si un árbol necesita únicamente documentación pública y el otro puede abrir incidencias internas, mantener las conexiones separadas facilita comprobar los límites.

Un servidor local puede depender de su directorio actual. Un proceso iniciado en cada carpeta puede recibir contextos diferentes aunque el comando sea el mismo. La documentación de OpenCode indica que hace falta un directorio de trabajo fijo para compartir conexiones locales entre proyectos y que una conexión compartida carece de raíces MCP. Por eso conviene empezar por un servicio de lectura que deje claro el alcance de sus recursos. Si la conducta de la herramienta depende del repositorio que la invoca, mide lo que cambia antes de compartir la conexión. Documentación de conexiones MCP compartidas

Las ejecuciones de un script también necesitan un cierre

OpenCode 2.2.6 añadió --archived para iniciar archivadas las sesiones de scripts o de integración continua y excluirlas de la lista normal. Esto cambia cómo se presentan las sesiones. Guarda el resultado del trabajo, la ruta del árbol y los resultados de pruebas donde puedan encontrarlos los revisores. Usa la opción cuando tengas una forma fiable de hallar el parche aunque la lista habitual esté vacía. Las notas del 6 de noviembre indican que --continue omite las sesiones archivadas. Versión 2.2.6 de OpenCode

La versión cambia también el ciclo de vida de una ejecución desde un script. Espera a que terminen los comandos en segundo plano, subagentes y tareas de imagen iniciados por la petición antes de salir. Las notas indican que esa espera carece de límite interno, así que un servidor de desarrollo o un observador de archivos puede dejarla abierta. Para una prueba automatizada, elige comandos que terminen cuando acaba la comprobación y limita el tiempo de la etapa de integración continua. Distingue una ejecución cancelada, una prueba fallida y un agente que declara éxito. Si vence el plazo, revisa el estado real de los cambios antes de reiniciar o integrarlos. Versión 2.2.6 de OpenCode

Cuando el piloto funcione, mide el ahorro más allá del mensaje final del agente. ¿Cuánto cuesta preparar una ejecución limpia? ¿Cuánto tarda un revisor en entender y verificar el cambio? ¿Con qué frecuencia alguien debe reparar una edición ajena a la tarea o investigar una herramienta atascada? Compara tareas de tamaño parecido e incluye el tiempo de preparación y revisión. Un árbol separado resulta más valioso cuando mantiene el parche lo bastante pequeño para que una persona se responsabilice de él.

Un directorio limpio hace visible quién responde por el cambio

La ventaja de esta opción es que quien revisa el resultado tiene un punto de partida claro. Puede ver la referencia, examinar el cambio y repetir la prueba mientras la otra persona sigue trabajando. Haz igual de explícitos los permisos de ejecución y la decisión de compartir conexiones. La entrega más clara es un parche pequeño que permite contestar por sí solo dónde empezó, qué cambió y qué pruebas justifican integrarlo.

Fuentes

• Captura oficial del terminal de OpenCode y licencia del repositorio

• Versión 2.2.6 de OpenCode, 6 de noviembre de 2026

• Documentación de la línea de comandos de OpenCode

• Permisos de OpenCode V2

• Conexiones MCP compartidas en OpenCode

• Manual de Git worktree

---

Para guardar las decisiones y los experimentos de tu trabajo en un registro en el que puedas buscar, crea una cuenta de Telli.sh.