Copilot CLI de GitHub: instalación, uso y precios

Cómo instalar Copilot CLI e iniciar sesión

Instala el paquete npm estable de GitHub, @github/copilot, con Node.js 22 o posterior. En Windows, GitHub también exige PowerShell v6 o superior. Si tu organización te proporciona Copilot, su administrador debe habilitar la política de Copilot CLI. Requisitos de instalación.

Ejecuta este comando en la terminal:

npm install -g @github/copilot

Si tu archivo ~/.npmrc contiene ignore-scripts=true, GitHub ofrece esta alternativa: npm_config_ignore_scripts=false npm install -g @github/copilot. La documentación también recoge winget install GitHub.Copilot para Windows, brew install --cask copilot-cli para macOS o Linux y curl -fsSL https://gh.io/copilot-install | bash para macOS o Linux. El requisito de Node corresponde a la instalación con npm. Comandos de instalación de GitHub.

Abre el repositorio en el que vas a trabajar y ejecuta copilot. Confirma que confías en esa carpeta, ya sea para la sesión actual o para las siguientes. Si aún no has iniciado sesión, escribe /login dentro de Copilot cuando te lo solicite. Primer inicio.

Selecciona GitHub.com o el nombre de host de GitHub Enterprise Cloud correspondiente a tu región de residencia de datos. En un equipo local con entorno gráfico, elige la autenticación mediante el navegador; en entornos remotos o sin interfaz gráfica, suele aparecer primero la opción de código de dispositivo. Completa la autorización en el navegador, autoriza las organizaciones pertinentes si usan SAML SSO y aprueba la aplicación GitHub Copilot CLI. Cuando termine el inicio de sesión, vuelve a la terminal. También puedes iniciar la autenticación desde el shell con copilot login. Instrucciones de autenticación.

Si la CLI usa una cuenta equivocada, revisa las variables COPILOT_GITHUB_TOKEN, GH_TOKEN y GITHUB_TOKEN: los tokens exportados explícitamente tienen prioridad sobre el inicio de sesión guardado. Para automatizaciones, GitHub admite un token de acceso personal con permisos específicos para una cuenta personal, con el permiso de cuenta Copilot Requests. Los tokens de acceso personal clásicos no son compatibles. Autenticación y prioridad de los tokens.

Primeras tareas: entender el código, corregir pruebas y abrir un PR

Empieza con una pregunta, sigue con un cambio que puedas verificar y termina con un pull request. Piensa en la CLI como un desarrollador que trabaja a tu lado: puede examinar el proyecto y utilizar herramientas, mientras tú decides qué acciones le permites realizar.

La tabla distingue entre comandos del shell y entradas dentro de una sesión interactiva de copilot. Todos los comandos y prompts que aparecen a continuación figuran en la documentación de GitHub. Cada interacción con un modelo consume créditos de IA; GitHub no publica un precio fijo en créditos para estas tareas. Cómo se factura la CLI.

Entiende el repositorio antes de modificarlo

Un desarrollador que llega a un proyecto desconocido puede empezar con el comando de la tabla que pide una explicación. El ejemplo de GitHub selecciona Claude Haiku 4.5: -p envía un único prompt y sale, -s oculta la salida adicional y --model elige el modelo. Si tu plan o las políticas aplicables no permiten usar ese modelo, abre una sesión interactiva y selecciona uno disponible con /model. Las cuentas Free y Student usan la selección Auto. Ejemplo de uso programático, acceso a los modelos.

Usa la explicación para localizar los puntos de entrada y la configuración de las pruebas; después, comprueba esos archivos por tu cuenta. Así tendrás un mapa inicial concreto que puedas contrastar, en lugar de recorrer directorios sin un objetivo claro.

Corrige una prueba con un criterio de éxito claro

Si mantienes un proyecto con una prueba que falla, ejecuta el comando de pruebas que realmente usa el repositorio, comparte la salida del fallo con Copilot y utiliza el prompt interactivo de la tabla. GitHub propone ese texto en su flujo de desarrollo guiado por pruebas, después de crear y revisar las pruebas que fallan. Si el fallo ya existe, aporta el contexto que falta: qué prueba falla y qué comportamiento debe conservar. Revisa el diff y vuelve a ejecutar la prueba correspondiente antes de aceptar el cambio. Flujo de pruebas de GitHub.

Cuando una prueba ya falla en CI, las comprobaciones automatizadas de un pull request existente, GitHub propone /pr fix ci focus on test failures. El comando investiga los registros, aplica correcciones y puede enviar cambios al remoto, por lo que conviene tratarlo como un flujo distinto al de corregir una prueba local. Requiere un PR existente para la rama actual. Corrección de fallos en CI.

Abre el pull request después de revisar el cambio

Si diriges un proyecto y quieres publicar una corrección pequeña, puedes usar /pr create desde la rama de trabajo después de revisar el cambio y crear el commit. Debes estar en un repositorio Git alojado en GitHub. Copilot envía los commits locales al remoto y crea el PR, siguiendo la plantilla del repositorio para el título y la descripción. Si la rama ya tiene un PR, el comando lo actualiza. Creación de un pull request.

El resultado es una entrega lista para revisar dentro del flujo de GitHub que ya usa el equipo. La responsabilidad por el contenido de la rama sigue siendo tuya.

Qué permisos pide Copilot antes de ejecutar comandos

Confiar en una carpeta y autorizar una herramienta son decisiones independientes. Cuando una acción requiere aprobación, puedes permitirla una vez, aprobar la herramienta durante la sesión actual o rechazarla y explicar el motivo. La aprobación para toda la sesión cubre la herramienta y sus opciones. Solicitudes de aprobación.

Las operaciones de solo lectura pueden ejecutarse automáticamente. Las acciones potencialmente destructivas, las escrituras y el acceso a URL requieren aprobación, salvo que ya la hayas concedido. Algunas solicitudes permiten guardar la aprobación para el repositorio o directorio. Los dominios de URL aprobados de forma permanente se mantienen entre sesiones. Permisos guardados.

GitHub muestra este ejemplo de permisos preconfigurados:

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

Permite ejecutar comandos de Git, pero bloquea los envíos al remoto. Las reglas de denegación prevalecen sobre las de autorización y las aprobaciones guardadas. /reset-allowed-tools borra las aprobaciones de la sesión y las aprobaciones de herramientas guardadas para la ubicación actual, y restablece los permisos definidos al iniciar la CLI. Reglas de autorización y denegación.

--allow-all-tools autoriza todas las herramientas disponibles. --allow-all o --yolo también autorizan todas las rutas y URL. GitHub recomienda usar estos permisos amplios en un entorno aislado. Para tus primeras tareas, mantén el proceso habitual de aprobación. Opciones de permisos amplios.

¿Qué planes la incluyen y cómo se factura el uso?

Todos los planes de Copilot incluyen la CLI: Free, Student, Pro, Pro+, Max, Business y Enterprise. No necesitas añadir una suscripción específica para la CLI a la licencia de Copilot que ya tienes. Estos son los precios mensuales y las cuotas actuales que recoge la página de planes de GitHub. Planes de Copilot.

La asignación flex es variable, así que los totales actuales no garantizan una capacidad permanente. Un crédito de IA equivale a $0.01 USD. El consumo depende de los precios del modelo elegido y de los tokens de entrada, salida y caché. El chat y la CLI utilizan la misma cuota. En los planes de pago, las sugerencias para completar código y las sugerencias de la siguiente edición siguen siendo ilimitadas y no consumen créditos de IA. Facturación individual.

Si ya tienes una suscripción Pro, seguirás pagando $10 al mes; el trabajo de los modelos en la terminal consume parte de la cuota actual de 1,500 créditos. Ese es el cálculo que ayuda a decidir: prueba el acceso que ya tienes y comprueba si la cuota compartida se ajusta a tu trabajo. Los usuarios individuales de pago pueden fijar un presupuesto para consumo adicional, cambiar a un plan superior o esperar al reinicio mensual. La tabla pública de precios no ofrece compras de créditos adicionales en Free. Cuotas individuales, límites de compra del plan Free.

Los créditos de Business y Enterprise se agrupan en una cuota compartida de la entidad de facturación. El consumo adicional de pago está habilitado de forma predeterminada y los administradores pueden desactivarlo. Un presupuesto por usuario o un límite de gasto de la empresa puede bloquear el acceso aunque quede otra cuota disponible. GitHub recomienda CLI 1.0.48 o posterior para que los datos de facturación y consumo se muestren correctamente. Facturación de organizaciones.

Después de una tarea, consulta /usage para ver los créditos de la sesión y el consumo de tokens del modelo. En una sesión interactiva, puedes ejecutar /limits set max-ai-credits NUMBER y sustituir NUMBER por la cuota que elijas. El mínimo es de 30 créditos. La función está en vista previa pública y establece un límite flexible: una respuesta en curso termina y puede superarlo ligeramente. Consulta del consumo, límites de sesión.

¿Qué modelos puedes usar en Copilot CLI?

Dentro de Copilot, usa /model para consultar las opciones disponibles, o --model si lo ejecutas desde el shell. La tabla actual de GitHub indica que los siguientes modelos son compatibles con la CLI; tu plan y las políticas del administrador pueden restringir el acceso. Modelos compatibles.

La tabla independiente de selección Auto para la CLI también incluye GPT-6.1 Sol. Free y Student solo permiten usar Auto. La disponibilidad cambia, así que consulta el selector para conocer las opciones actuales de tu cuenta. Auto y disponibilidad por plan.

Cómo añadir instrucciones del proyecto y herramientas MCP

Define las reglas de trabajo del repositorio antes de pedir cambios recurrentes. Las instrucciones personalizadas son archivos Markdown que Copilot incorpora como contexto. Guarda los comandos de compilación, las pruebas y las convenciones generales del proyecto en .github/copilot-instructions.md. Para reglas que solo se aplican a determinadas rutas, usa .github/instructions/**/*.instructions.md con patrones applyTo. Instrucciones personalizadas.

La CLI también detecta AGENTS.md, CLAUDE.md, .claude/CLAUDE.md y GEMINI.md. Puedes guardar las preferencias generales del usuario en ~/.copilot/copilot-instructions.md o ~/.copilot/instructions/**/*.instructions.md. Las instrucciones aplicables se combinan; GitHub no define un orden general de prioridad entre ellas. Procura que sean coherentes y usa /instructions para consultar o desactivar los archivos detectados. Detección y combinación de instrucciones.

MCP, Model Context Protocol, conecta un agente con herramientas y datos externos. Es como añadir una conexión a un servicio en tu entorno de trabajo. El servidor MCP de GitHub ya viene integrado. Para añadir otro servidor, usa /mcp add, cambia de campo con Tab y guarda con Ctrl+S. Los servidores locales o stdio ejecutan un proceso; los servidores HTTP se conectan a un endpoint remoto. También se admite SSE heredado. Cómo añadir servidores MCP.

El ejemplo de GitHub para la terminal es copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp. La configuración del usuario se guarda en ~/.copilot/mcp-config.json; la del proyecto puede usar .mcp.json o .github/mcp.json. La guía específica de MCP indica que las políticas configuradas de registro de servidores y lista de permitidos de la organización se aplican a la CLI. Ejemplo para la terminal, configuración y políticas.

Cuándo elegir la CLI, el IDE u otro agente

Mi recomendación: empieza con Copilot CLI si la tarea ya se desarrolla en la terminal y tienes una licencia de Copilot. Elige la extensión del IDE cuando quieras trabajar junto al archivo que estás editando, revisar los cambios visualmente y seguir dentro del editor. Nuestra comparativa de Cursor y GitHub Copilot te ayuda a tomar esa decisión.

Además de las primeras tareas, estas son otras posibilidades útiles:

• Quien mantiene un proyecto y prepara una revisión puede pedir una revisión del código de la rama de trabajo, investigar los hallazgos y entregar el diff a una persona para que lo revise. El resultado es una lista de comprobaciones concreta, siempre que los hallazgos resistan la verificación. GitHub documenta flujos de revisión local. Guía de revisión.
• Un desarrollador que atiende comentarios de un PR puede usar /pr fix feedback, examinar los cambios propuestos y aprobar los envíos al remoto. Así mantiene juntas las modificaciones solicitadas y la conversación. El comando puede responder a los hilos de revisión atendidos y marcarlos como resueltos, por lo que conviene revisar su alcance antes de aprobarlo. Flujo para atender comentarios.

Considera otro agente de terminal si necesitas una cuota de suscripción distinta, otra configuración de proveedores o más control sobre el propio agente. Nuestra comparativa de alternativas a Claude Code y sus costos en la terminal te ayuda a decidir esa compra. Antes, comprueba si las opciones de modelos de Copilot cubren lo que necesitas: GitHub también documenta cómo usar tu propio proveedor, incluidos modelos locales compatibles. Esa vía requiere una configuración independiente del proveedor, llamadas a herramientas y streaming; su configuración es distinta de la que utiliza tu cuota de Copilot. Uso de un modelo propio.

Qué podría crear un equipo pequeño a partir de esta herramienta

Un paquete para familiarizarse con un repositorio es la oportunidad inicial más sólida. Entre las búsquedas de los desarrolladores figuran “how to understand a new codebase” y “ai tool to understand codebase.” Un equipo podría vender a responsables de ingeniería un paquete actualizado de notas de arquitectura, instrucciones de compilación verificadas y tareas de incorporación bien delimitadas. La versión mínima útil abarcaría el repositorio del cliente y demostraría el flujo de explicación, pruebas y PR. La dificultad: los prompts genéricos son fáciles de copiar; el cliente pagaría por el conocimiento del proyecto y su mantenimiento.

Otra posibilidad es un flujo de preparación de revisiones. Las búsquedas de “ai code review tools” y “ai powered code review platform” apuntan a esa necesidad. Un equipo podría combinar instrucciones del proyecto y contexto conectado de las incidencias para generar un paquete de revisión con los cambios, los resultados de las pruebas y las preguntas pendientes. El comprador sería un responsable de equipo que quisiera estandarizar las entregas. La dificultad: hay que validar los hallazgos generados y el flujo debe aportar suficiente valor junto a las funciones de revisión que GitHub ya ofrece. Son posibilidades de producto, no resultados demostrados.

Límites que conviene tener en cuenta

La CLI puede generar un cambio que parezca correcto y esté equivocado. La guía de uso responsable de GitHub advierte de que las respuestas generadas pueden ser inexactas o incompletas e indica que se deben verificar el código y los comandos de la CLI. Superar las pruebas pertinentes y revisar el diff siguen siendo parte del trabajo. Uso responsable.

Confiar en una carpeta no garantiza el aislamiento. GitHub describe el alcance de los permisos de directorio como heurístico y no garantiza la protección de todos los archivos que estén fuera de los directorios de confianza. Inicia la CLI en el repositorio en el que quieras trabajar. Si necesitas restricciones más estrictas, /sandbox enable activa el aislamiento local de las herramientas; los entornos aislados locales y en la nube de GitHub están en vista previa pública. Confianza en directorios y aislamiento.

Los límites de acceso y gasto siguen vigentes. Un modelo que figure en la documentación puede no estar disponible en tu plan o estar deshabilitado por una política. El uso de la CLI comparte créditos con otras tareas de Copilot y el límite de sesión en vista previa puede superarse ligeramente. Los presupuestos de la organización pueden detener el uso sin que se cambie automáticamente a un modelo más barato. Acceso a modelos, límites de sesión, comportamiento de los presupuestos.

En tu próxima sesión de trabajo, elige una prueba que realmente falle en una rama que puedas revisar. Pide una explicación del código pertinente, aprueba las solicitudes de herramientas para la corrección, vuelve a ejecutar la prueba, consulta /usage y abre el PR. Esa experiencia te dará una base concreta para decidir si el flujo encaja en tu trabajo y cuánto consume.

Si quieres un flujo de trabajo para tu repositorio adaptado a las comprobaciones de tu equipo y sus herramientas conectadas, creamos automatizaciones con IA.