GitHub Copilot computer use ya está en vista previa pública desde el 1 de octubre de 2026 en Copilot CLI y en la aplicación de GitHub Copilot para macOS y Windows. La novedad no va de que un asistente escriba más código, sino de algo más delicado: que pueda interactuar con aplicaciones de escritorio, leer contexto visual, pulsar controles, introducir texto y moverse por flujos que no tienen API, CLI ni integración MCP.
La lectura útil para equipos de desarrollo es bastante clara: Copilot empieza a cubrir una zona que hasta ahora quedaba fuera de la automatización estructurada, especialmente herramientas heredadas, software interno con interfaz gráfica, presentaciones, navegadores, formularios y procesos de escritorio. Pero esa potencia solo tiene sentido si se usa con permisos estrechos, objetivos concretos y revisión humana, porque la propia documentación de GitHub avisa de riesgos reales cuando un agente interpreta interfaces visuales cambiantes.
En paralelo, GitHub también ha presentado dynamic workflows para Copilot CLI, la app de Copilot y el SDK. Ahí la idea es distinta pero complementaria: definir en código procesos reutilizables con pasos, agentes, límites, pausas y resultados estructurados. Juntas, ambas piezas dibujan un Copilot menos centrado en el chat y más orientado a trabajo operativo repetible.
Resumen rápido para lectores y asistentes
- Fuente principal: GitHub publicó el anuncio de computer use el 1 de octubre de 2026 y lo describe como una vista previa pública.
- Qué permite: Copilot puede leer contenido accesible y contexto visual, hacer clic, escribir, pulsar teclas, desplazarse, arrastrar elementos y navegar flujos entre aplicaciones.
- Dónde funciona: Copilot CLI y GitHub Copilot app en macOS y Windows, según la documentación oficial.
- Por qué importa: abre la puerta a automatizar software de escritorio, herramientas heredadas y procesos GUI-only que no tienen API ni MCP.
- Límite clave: GitHub recomienda usar herramientas estructuradas, API, terminal o MCP cuando estén disponibles, porque suelen ser más predecibles.
- Riesgo principal: interfaces cambiantes, contenido inesperado o permisos demasiado amplios pueden provocar acciones no deseadas.
- Complemento relevante: dynamic workflows permite llevar procesos complejos a flujos definidos en código, con subagentes, pausas y límites de consumo.
Qué ha pasado exactamente
GitHub anunció el 1 de octubre de 2026 que GitHub Copilot puede interactuar con aplicaciones de escritorio mediante computer use. La compañía lo sitúa en vista previa pública y lo limita, por ahora, a Copilot CLI y a la aplicación de GitHub Copilot en macOS y Windows.
El anuncio enumera acciones bastante concretas: leer contenido accesible y contexto visual, hacer clic en controles, introducir y editar texto, pulsar teclas, hacer scroll, arrastrar elementos y navegar flujos entre aplicaciones. No es una función menor, porque desplaza a Copilot desde el entorno clásico de repositorio, terminal o editor hacia aplicaciones de escritorio que muchas empresas siguen usando para trabajo real.
El mismo día GitHub también publicó dynamic workflows en Copilot CLI y la app de Copilot. No son lo mismo que computer use, pero ayudan a entender hacia dónde va el producto: procesos más explícitos, repetibles y observables, no solo prompts sueltos.
Por qué importa para equipos de desarrollo
Hasta ahora, la automatización seria funcionaba mejor cuando el sistema tenía una interfaz estructurada: API, CLI, SDK, webhook, MCP, archivo de configuración o base de datos. El escritorio seguía siendo una frontera incómoda. Muchas tareas pasan por aplicaciones internas, paneles antiguos, instaladores, presentaciones, hojas de cálculo, navegadores con permisos corporativos o herramientas gráficas que nunca recibieron una API decente.
Computer use intenta entrar justo ahí. Su valor no está en sustituir al terminal cuando el terminal ya resuelve bien una tarea. Está en esos procesos donde el humano acaba copiando información entre ventanas, revisando formularios, comprobando estados visuales o moviendo datos a través de software que no fue pensado para automatizarse.
Esto conecta con una línea que ya hemos seguido en Aketdoy: agentes que dejan de ser solo conversación y empiezan a operar en superficies concretas. Lo vimos con GitHub HydraFusion en Copilot, con Modern Web Guidance de Google y con WebMCP en Chrome. La diferencia es que computer use no exige que la aplicación haya nacido preparada para agentes; interpreta la interfaz que ya existe.
Cómo funciona computer use en la práctica
La documentación oficial de computer use en GitHub Copilot resume el enfoque de forma bastante pragmática: Copilot puede interactuar con aplicaciones de escritorio para automatizar tareas que no se pueden completar con una herramienta más directa.
Eso último es importante. GitHub no lo presenta como reemplazo universal de APIs, MCP, comandos de terminal o herramientas de navegador. De hecho, la propia documentación recomienda preferir esas rutas cuando existan, porque suelen ofrecer información más estructurada y resultados más previsibles.
En un flujo real, computer use puede servir para:
- Revisar información visible en una aplicación de escritorio heredada.
- Actualizar contenido en una presentación o documento con interfaz gráfica.
- Introducir datos en software interno que no ofrece integración programática.
- Mover información entre aplicaciones como parte de un proceso de varios pasos.
- Resumir notificaciones o estados visibles en una ventana concreta.
La activación también es explícita. En Copilot CLI, GitHub indica el comando /computer on, con /computer show para consultar el estado y /computer off para desactivarlo. En la app de Copilot, la opción se activa desde Settings, dentro de Computer Use.
Permisos, riesgos y límites reales
La parte menos vistosa es la más importante. Computer use está desactivado por defecto y GitHub explica que el usuario debe habilitarlo antes de que el agente tenga esas herramientas disponibles. Además, el control se cruza con los permisos del sistema operativo y con las políticas de la organización.
En macOS, por ejemplo, GitHub menciona permisos de Accesibilidad y Grabación de pantalla. En entornos empresariales, los administradores pueden deshabilitar la función mediante ajustes gestionados. Y si el usuario concede acceso permanente a una aplicación, conviene revisar después esa lista y retirar aprobaciones que ya no hagan falta.
El riesgo no es teórico. GitHub advierte de que computer use interpreta interfaces que cambian entre versiones, estados de ventana y sistemas operativos. Eso puede hacer que seleccione un control equivocado, escriba en un lugar incorrecto, repita acciones o se bloquee ante controles dinámicos. También puede ver información sensible presente en ventanas abiertas.
Por eso la regla práctica debería ser esta: computer use es útil para automatizar flujos visuales, pero no debería convertirse en permiso amplio para “hacer cosas en mi escritorio”. Cuanto más alto sea el impacto de una aplicación, más estrecha debería ser la autorización y más revisión humana debería haber antes de modificar datos.
Dónde encajan los dynamic workflows
Los dynamic workflows de GitHub Copilot atacan otro problema: cómo repetir procesos complejos sin depender de que cada sesión de chat improvise una estrategia nueva.
Según GitHub, un dynamic workflow es un programa que define cómo se lleva a cabo una tarea. Puede combinar pasos automatizados, agentes, herramientas, llamadas a servicios, pausas para revisión y resultados estructurados. Los pasos pueden ejecutarse en secuencia, en paralelo o mezclando ambas cosas.
La diferencia frente a un modo autónomo normal es quién define el proceso. En un chat clásico, el agente decide los pasos durante la conversación. En un dynamic workflow, el autor define condiciones, límites y traspasos. Eso encaja mejor con tareas que una organización quiere repetir: revisión de muchos ficheros, investigación de incidencias, migraciones controladas, barridos de patrones o procesos de release con checkpoints.
La combinación con computer use es evidente, aunque debe tratarse con cuidado: un workflow puede ordenar fases, límites y verificaciones; computer use puede cubrir la parte visual de una aplicación sin API. Pero si se mezclan, conviene que las acciones de escritorio queden muy acotadas, con permisos claros y puntos de pausa antes de cambios sensibles.
Cuándo tiene sentido usarlo
La mejor forma de valorar computer use no es preguntarse “qué puede controlar”, sino “qué no puedo automatizar mejor por otro camino”. Si existe una API fiable, una integración MCP, un comando de terminal o un SDK oficial, normalmente será mejor empezar por ahí.
| Situación | Ruta recomendable | Motivo |
|---|---|---|
| Actualizar código, ejecutar tests o modificar archivos | CLI, editor, repositorio o workflow definido | Más trazabilidad, diffs revisables y menor ambigüedad visual. |
| Consultar o mover datos en una app sin API | Computer use con permiso limitado | Puede cubrir software GUI-only, siempre con supervisión. |
| Repetir un proceso largo con fases claras | Dynamic workflow | Permite codificar pasos, límites, pausas y resultados estructurados. |
| Acciones sensibles sobre datos financieros, personales o productivos | Proceso humano o automatización auditada | El impacto de un clic equivocado puede ser demasiado alto. |
Una regla práctica
Usa computer use cuando el cuello de botella sea una interfaz visual inevitable. Usa dynamic workflows cuando el problema sea repetir una secuencia compleja con más control. Y usa APIs, terminal o MCP cuando el sistema ya ofrezca una ruta estructurada.
Conclusión
GitHub Copilot computer use no convierte al asistente en un operador mágico de escritorio, pero sí añade una pieza importante al mapa de los agentes de desarrollo: la posibilidad de actuar sobre aplicaciones que antes quedaban fuera de la automatización programable. Eso puede ahorrar trabajo gris en empresas con herramientas antiguas o procesos GUI-only.
La otra mitad de la noticia es que Copilot se está moviendo hacia procesos más gobernables. Dynamic workflows, límites, permisos, pausas y trazabilidad importan tanto como la capacidad de hacer clic. El salto no está en que el agente “vea la pantalla”, sino en que cada vez hay más formas de convertir trabajo disperso en procesos revisables.
Fuentes y enlaces útiles
FAQ sobre GitHub Copilot computer use
¿Qué es GitHub Copilot computer use?
Es una capacidad en vista previa pública que permite a Copilot interactuar con aplicaciones de escritorio en Copilot CLI y en la app de GitHub Copilot para macOS y Windows.
¿Computer use sustituye a las API o al terminal?
No debería. GitHub recomienda usar herramientas más directas y estructuradas cuando existan, como API, MCP, comandos de terminal, herramientas de navegador o acceso al sistema de archivos.
¿Está activado por defecto?
No. La documentación oficial indica que computer use está desactivado por defecto y debe habilitarse antes de que el agente pueda usar esas herramientas.
¿Cuál es el principal riesgo?
Que el agente interprete mal una interfaz visual, pulse un control equivocado o actúe sobre información sensible visible en pantalla. Por eso conviene limitar permisos y revisar acciones importantes.
¿Qué aportan los dynamic workflows?
Permiten definir procesos reutilizables en código, con pasos, subagentes, límites, pausas y resultados estructurados. Son útiles cuando una tarea compleja debe repetirse con más control que un prompt aislado.