VS Code 1.144 lleva la sesión de programación más allá de la tapa del portátil
Los hosts persistentes de agentes y las sesiones en la nube cambian cómo sobrevive el trabajo a una desconexión. Qué es estable, qué sigue en versión preliminar y cómo probar el traspaso sin perder cambios.
Empiezas una tarea de programación en el escritorio, la consultas desde otro dispositivo y vuelves después para revisar las diferencias. La experiencia útil es un trabajo continuo, con las mismas instrucciones y decisiones visibles. Reconstruir la conversación tras cada cambio de dispositivo es otra forma de trabajo de desarrollo.
VS Code 1.144 se publicó como versión estable el 28 de octubre de 2026. Sus notas reúnen continuidad de sesiones de agentes y gestión remota con funciones que mantienen sus propias etiquetas Preview o Experimental. Las sesiones en la nube se ejecutan en infraestructura de GitHub, por lo que pueden continuar mientras el portátil está desconectado. Notas oficiales.
Esta guía explica la diferencia entre un cliente y el lugar donde se ejecuta el trabajo, qué aporta Agent Host Protocol y cómo evaluar una sesión continua mediante un traspaso real a revisión de código.
Captura oficial de Remote Environments en Visual Studio Code 1.144. Used with permission from Microsoft. Fuente de la imagen · Licencia y notas de la imagen.
Cerrar una ventana y detener un proceso de trabajo son hechos distintos
La interfaz de programación muestra mensajes, archivos y solicitudes de aprobación. El proceso que realiza la tarea puede estar en otro lugar. Al separar esas funciones, cerrar la interfaz no tiene por qué significar abandonar la tarea, siempre que el host y su entorno sigan disponibles.
El resumen de Universe publicado por Microsoft el 28 de octubre describe Agent Host como un proceso independiente que administra sesiones, entornos de agentes, modelos, archivos y terminales. Indica que Agent Host Protocol ha llegado a la versión 1.0 y conecta clientes con el estado de una sesión continua. La distinción arquitectónica ayuda a evaluar qué significa realmente «seguir trabajando».
Un host local sigue dependiendo del equipo local. Uno remoto depende de su equipo y de las conexiones correspondientes. Una sesión en la nube dispone de un entorno alojado por separado. Elige la ubicación de ejecución según lo que deba seguir disponible cuando desaparezca el cliente.
Piensa en el cliente como una ventana de una sala de control. Otra ventana puede mostrar el mismo trabajo, pero no mueve la maquinaria que hay debajo. Un teléfono que muestra una sesión no convierte un ordenador local suspendido en un servidor permanente.
Nuestra opinión: la persistencia resulta útil cuando la identidad de la tarea sobrevive junto a su ejecución. La sesión debería aclarar qué repositorio utiliza, qué cambios ha producido y qué decisión espera. Mantener vivo un proceso es un logro menor.
Explicación original de las responsabilidades de cliente y host, basada en el resumen de VS Code para Universe. Es un modelo simplificado de planificación, no una topología de red.
AHP sincroniza la sesión que muestran las interfaces
El sitio oficial de Agent Host Protocol, consultado el 2 de noviembre, describe AHP como un protocolo de presentación bidireccional basado en estado. Los clientes operan sobre un estado compartido; el host difunde acciones y resuelve conflictos. Al reconectar puede enviar las acciones perdidas o una instantánea actual para poner al día la interfaz.
Importa porque una sesión contiene más que una transcripción. Puede incluir una acción pendiente de aprobación, un terminal en ejecución o un archivo modificado. Si dos interfaces muestran versiones incoherentes de esos hechos, quien maneja la sesión puede decidir mal aunque el código generado sea bueno.
Los ejemplos de reconexión del protocolo muestran cómo se concilian las acciones pendientes del cliente con el estado del host. La consecuencia práctica es sencilla: reconectar debería recuperar la situación actual del trabajo, incluido qué ocurrió con una petición anterior. No debería obligar a adivinar si una aprobación llegó antes de que fallara la red.
Un protocolo compartido también establece un límite para la interoperabilidad. Cada cliente necesita entender el estado y las acciones que muestra. La existencia de un protocolo no significa que todas las herramientas puedan conectarse ya con todos los proveedores o mostrar todas las funciones de forma idéntica.
Si tu equipo compara interfaces, inspecciona las decisiones relevantes para su trabajo. ¿El cliente alternativo muestra una solicitud de permiso pendiente? ¿Identifica los archivos modificados y el estado de la tarea? ¿Volver al editor conserva el mismo trabajo o inicia una segunda conversación?
Una versión estable y una función preliminar son etiquetas distintas
La página de VS Code 1.144 identifica la versión como Stable, mientras Cloud Automations, la generación de imágenes y los conectores de Copilot conservan la etiqueta Preview; el uso del ordenador y las funciones de conjunto de trabajo figuran como Experimental. Las sesiones en la nube requieren un plan de pago de Copilot y están sujetas a la política de la organización. Estado de versión y funciones, 28 de octubre, consultado el 2 de noviembre.
Es una combinación habitual en un editor extensible: una aplicación estable puede contener funciones individuales con distinta madurez. La decisión de adopción debe corresponder a la función y al proceso, no solo al número de versión.
| Opción de ejecución | Qué debe seguir disponible | Pregunta antes de empezar |
|---|---|---|
| Host local de agentes | Entorno local de ejecución | ¿Qué ocurre si este equipo se suspende o detiene? |
| Host remoto de agentes | Host remoto y servicios necesarios | ¿Quién responde de disponibilidad, acceso y estado del espacio de trabajo? |
| Sesión en la nube | Entorno de ejecución administrado por el proveedor | ¿Permiten la tarea este repositorio, plan y organización? |
La tabla compara operaciones, no promete un comportamiento idéntico entre entornos. Siguen importando los requisitos de la extensión, el modelo y el entorno de agentes concretos. Prueba la combinación que tu equipo pretende utilizar.
Para una capacidad experimental, elige un ejercicio separado y reversible. Para evaluar la continuidad esencial, empieza por el proceso mínimo que demuestre el traspaso. Combinar varias novedades dificulta identificar qué parte produjo un resultado inesperado.
Tres tareas ilustrativas muestran dónde ayuda la continuidad
Un desarrollador puede encargar una corrección acotada y revisarla después
Imagina que un desarrollador pide a una sesión en la nube corregir una prueba fallida de un analizador en un repositorio. La instrucción nombra el fallo, el comportamiento relevante y la verificación esperada. Después consulta el progreso desde otro cliente compatible antes de volver al editor para revisar.
El criterio de aceptación debería ser el habitual: la corrección resuelve el comportamiento, pasan las comprobaciones relevantes y las diferencias son adecuadas. Continuar con el portátil cerrado es útil porque cambia cuándo puede hacerse el trabajo. No demuestra que el resultado esté listo para integrarse.
Para el traspaso, pide conservar el comando exacto y el resultado de la prueba. «Las pruebas pasan» cuesta más de valorar que una comprobación identificada y vinculada a una revisión concreta. Quien revisa necesita evidencia suficiente para entender el resultado sin reconstruir toda la conversación.
Si una aprobación o un servicio ausente bloquea la tarea, la sesión debería mostrarlo. Un trabajo activo que no puede avanzar es distinto de uno que progresa. Esa visibilidad ayuda a decidir si intervenir, cambiar el alcance o dejarlo en espera.
Un mantenedor puede investigar incidencias separadas sin mezclar sus archivos
Un mantenedor ilustrativo podría pedir a una sesión reproducir un fallo mientras otra examina documentación. Puede aprovechar las esperas si las tareas tienen límites claros. También exige vincular cada resultado con su espacio de trabajo y contexto de revisión.
Define responsabilidades antes de empezar. Nombra archivos o subsistema, rama o espacio de trabajo y entrega esperada de cada sesión. Si ambas deben modificar el mismo contrato, decide cómo conciliar sus hallazgos antes de aplicar los dos cambios.
Revisa un resultado respecto a un estado conocido del repositorio. De lo contrario, una prueba satisfactoria puede depender de cambios no revisados de otra sesión. El límite de un espacio de trabajo ayuda a establecer de dónde procede un resultado válido.
El beneficio es una cola de revisión más clara, no simplemente más agentes simultáneos. Dos investigaciones bien delimitadas pueden reducir incertidumbre; varias modificaciones solapadas pueden aumentarla. La interfaz Agents es útil cuando permite ver cuál de esas situaciones está surgiendo.
Un equipo puede probar una tarea periódica antes de confiar en su calendario
Como piloto ilustrativo de automatización, considera una revisión periódica que identifique enlaces de documentación que necesitan atención. Empieza por un informe de solo lectura y una entrega concreta. Deja que una persona inspeccione el resultado antes de ampliar la tarea para crear cambios.
El estado Preview de Cloud Automations importa porque el trabajo recurrente añade responsabilidad operativa. Una tarea aceptable una vez puede necesitar controles de frecuencia, responsable y respuesta clara al fallo antes de programarse. Prueba esos requisitos aparte de la calidad lingüística de sus resultados.
El equipo debería saber dónde registra cada ejecución la revisión del repositorio, los hallazgos y las peticiones externas. Si no termina, el registro debería indicar qué quedó sin resolver. Una tarea periódica resulta útil cuando su responsable distingue una situación sin cambios de una comprobación fallida.
Empieza con un repositorio y un alcance modesto. Amplía solo después de observar ejecuciones normales, una bloqueada deliberadamente y la revisión de su entrega. Son pasos propuestos para un piloto, no afirmaciones de haber probado personalmente la versión.
Tu trabajo sin confirmar necesita un traspaso explícito
Las notas de 1.144 indican que las sesiones en la nube usan un espacio separado y no copian automáticamente los cambios locales sin confirmar. Desde Chat o Agents se puede seleccionar Cloud, elegir un repositorio de GitHub, continuar, responder aprobaciones y revisar cambios; las sesiones existentes pueden reabrirse desde la lista. Instrucciones de sesiones en la nube.
Ese espacio separado es importante para quien trabaja en una copia activa. Un archivo local puede ser esencial aunque no exista en el estado del repositorio que ve la sesión en la nube. Antes de transferir la tarea, identifica la revisión inicial y la vía autorizada para aportar material adicional.
No confundas cambiar de interfaz con transferir archivos. Continuar la conversación no demuestra que se hayan trasladado todos los archivos locales o servicios en ejecución. La sesión puede conservar su intención y seguir necesitando acceso explícito al material requerido.
Para un informe ilustrativo de fallo, incluye la entrada problemática de forma aprobada y reproducible. Indica si el agente debe utilizar datos de prueba confirmados o material recién aportado. Así tiene un punto de partida concreto y evita investigar largamente un estado que nunca contuvo el problema.
La revisión final debería comprobar el mismo límite a la inversa. Determina dónde están los cambios propuestos y cómo entrarán en la rama de trabajo. Conserva las modificaciones locales activas mientras revisas y aplicas el resultado. La ventaja de un espacio remoto no debería perjudicar trabajo local cuyo estado sea incierto.
Flujo original de aceptación de una tarea continua de programación. Combina el límite documentado del espacio en la nube con la revisión habitual de ingeniería; no comunica resultados de pruebas independientes.
Un recorrido de diez minutos demuestra menos que una tarea completa
Es fácil evaluar lo visible de la continuidad: una sesión aparece en la lista, un cliente reconecta, llega un mensaje. Son comprobaciones útiles, pero el objetivo del desarrollador es un trabajo terminado cuyo estado sobrevive al traspaso.
Elige una tarea pequeña que termine con una entrega inspeccionable. Puede servir un dato de prueba, una corrección documental o un cambio aislado de comportamiento si el repositorio ofrece una comprobación clara. Debe ser significativa para revelar estado y permisos sin ampliar innecesariamente la primera prueba.
- Actualiza y verifica la versión instalada. Usa la búsqueda de actualizaciones de VS Code y confirma la versión. Revisa las etiquetas de cada función en las notas oficiales.
- Elige un entorno de ejecución autorizado. Confirma acceso al repositorio, requisitos del plan y política de la organización. Decide si corresponde un host local, remoto o en la nube.
- Registra el estado inicial. Anota repositorio y revisión. Conserva cambios locales e identifica las entradas que necesitará el espacio elegido.
- Da una instrucción acotada. Nombra el comportamiento deseado, el alcance y el comando de verificación. Define la entrega que esperas revisar.
- Prueba el traspaso. Abandona el cliente y reconecta mediante una interfaz compatible disponible. Comprueba el estado de la misma sesión, las aprobaciones pendientes y el trabajo nuevo.
- Vuelve al código. Inspecciona diferencias y evidencia de verificación. Confirma que las comprobaciones corresponden a la revisión que estás evaluando.
- Registra el resultado y los límites restantes. Separa reconexión satisfactoria, tarea completada y cambio aceptado. Son hitos relacionados con evidencias diferentes.
Si falla la prueba, diagnostica el límite que falló. Un dato de prueba ausente exige reparar el espacio; una llamada bloqueada exige decidir permisos; un host no disponible exige decidir el entorno de ejecución. Repetir la misma instrucción rara vez resuelve un problema ajeno a ella.
Mantén concreto el primer resultado. «Esta tarea continuó en este entorno y produjo estas diferencias revisadas» es una conclusión operativa útil. Indica a un compañero qué puede repetirse y dónde importan las condiciones.
Una sesión persistente debería facilitar seguir las responsabilidades
VS Code 1.144 sitúa más partes del trabajo de agentes en un espacio continuo: donde las instrucciones se convierten en acciones y estas en cambios revisables. AHP aporta una dirección de estado compartido para clientes, mientras la ubicación determina qué sigue ejecutándose tras desconectar un dispositivo.
La mejora significativa es poder dejar un trabajo, volver y seguir entendiéndolo. Cuando la sesión conserva su estado de origen, decisiones y verificación, la tapa del portátil pasa a ser un detalle de horario en lugar del límite del trabajo.
Fuentes
- Notas de Visual Studio Code 1.144, versión estable del 28 de octubre de 2026; consultadas el 2 de noviembre de 2026.
- VS Code Wrapped: GitHub Universe 2026, 28 de octubre de 2026.
- Microsoft Agent Host Protocol, especificación v1.0.0 y resumen del estado compartido, consultados el 2 de noviembre de 2026.
Conserva el material que sustenta una decisión
Telli.sh es una opción para conservar material autorizado de las fuentes junto a las notas que has revisado. Crea un espacio de notas.