Kiro Setup Guide (Español)
Contexto: por qué pueden producirse conflictos entre las cuentas de Kiro
Sección titulada «Contexto: por qué pueden producirse conflictos entre las cuentas de Kiro»El backend de Kiro utiliza registros de clientes OIDC de AWS SSO para realizar un seguimiento de las sesiones activas. La restricción fundamental es que cada registro de cliente OIDC solo admite una sesión activa a la vez. Cuando un segundo dispositivo o usuario se autentica utilizando el mismo cliente registrado, el backend invalida el token de actualización de la primera cuenta.
Este es el mismo mecanismo que causa problemas al ejecutar kiro-cli login en un
equipo donde ya se ha iniciado sesión con otra cuenta de Kiro: el nuevo inicio de sesión revoca
el token de la primera cuenta.
Cómo resuelve esto OmniRoute (v3.8.0+)
Sección titulada «Cómo resuelve esto OmniRoute (v3.8.0+)»A partir de v3.8.0, OmniRoute llama a registerClient() (AWS SSO OIDC) durante cada
importación de una conexión de Kiro. Esto proporciona a cada conexión de OmniRoute su propio
registro de cliente OIDC dedicado. Como cada registro de cliente es independiente, actualizar
o volver a autenticar una cuenta no afecta al token de actualización de ninguna otra cuenta.
El aislamiento se aplica a los métodos de importación mediante token de actualización, mientras que la autenticación con clave de API evita por completo las sesiones de actualización OIDC:
| Método de importación | Estado del aislamiento |
|---|---|
| Flujo de código de dispositivo de AWS Builder ID / IDC | Aislado desde que se introdujo el flujo de código de dispositivo |
| Importar token (pegado manual del token de actualización) | Aislado desde v3.8.0 |
| Inicio de sesión con Google / GitHub | Aislado desde v3.8.0 |
| Importación automática (SQLite de kiro-cli) | Aislado desde v3.8.0 (la ruta de SQLite ya estaba aislada; la alternativa de caché de SSO ahora también está aislada) |
| Clave de API (clave de CodeWhisperer de larga duración) | Sin sesión de actualización; la clave se valida y almacena como credencial de portador |
Nota de migración para conexiones creadas antes de v3.8.0
Sección titulada «Nota de migración para conexiones creadas antes de v3.8.0»Las conexiones importadas antes de v3.8.0 no tienen almacenado un registro de cliente OIDC
dedicado en providerSpecificData. Estas conexiones siguen funcionando, pero utilizan el
endpoint compartido de actualización de autenticación social, lo que significa que dos de esas conexiones aún pueden invalidarse
entre sí.
Para obtener aislamiento: elimina la conexión antigua desde Panel → Proveedores y vuelve a importarla mediante cualquiera de los flujos de importación compatibles. Todas las conexiones nuevas recibirán automáticamente su propio registro de cliente.
Añadir dos cuentas de Kiro en paralelo
Sección titulada «Añadir dos cuentas de Kiro en paralelo»Requisitos previos
Sección titulada «Requisitos previos»- OmniRoute v3.8.0 o posterior.
- Una cuenta de Kiro operativa (correo electrónico + contraseña, o inicio de sesión con Google o GitHub).
- Opcionalmente, una segunda cuenta de Kiro.
Paso 1: importar la primera cuenta
Sección titulada «Paso 1: importar la primera cuenta»- Abre Panel → Proveedores → Añadir proveedor → Kiro.
- Elige una de estas opciones:
- Importar token — pega un token de actualización que comience por
aorAAAAAG. - Clave de API — pega una clave de API de Kiro / CodeWhisperer de larga duración.
- Inicio de sesión con Google / GitHub — completa el flujo de OAuth en el navegador.
- Importación automática — haz clic en el botón; OmniRoute lee las credenciales de la
base de datos local de kiro-cli o de
~/.aws/sso/cache.
- Importar token — pega un token de actualización que comience por
- La conexión se guarda. Los flujos con token de actualización registran automáticamente un cliente OIDC dedicado. Los flujos con clave de API validan la clave con AWS y no almacenan ningún token de actualización.
Paso 2: importar la segunda cuenta
Sección titulada «Paso 2: importar la segunda cuenta»Repite el paso 1 para la segunda cuenta. Como cada importación crea un registro de cliente OIDC independiente, las dos conexiones quedan completamente aisladas.
Paso 3: comprobar que ambas conexiones estén activas
Sección titulada «Paso 3: comprobar que ambas conexiones estén activas»- Panel → Proveedores — ambas conexiones de Kiro deberían mostrar el estado Activo.
- Panel → Estado — ambas conexiones deberían superar la comprobación del estado de sus tokens.
Paso 4: utilizar una combinación para enrutar entre cuentas
Sección titulada «Paso 4: utilizar una combinación para enrutar entre cuentas»Crea una combinación con ambas conexiones como destinos para equilibrar la carga o conmutar por error entre ellas:
kiro/kiro-dev → kiro/kiro-proConsulta FEATURES.md y la documentación de enrutamiento para obtener información sobre la configuración de combinaciones.
Usuarios empresariales / IDC
Sección titulada «Usuarios empresariales / IDC»Para las cuentas de AWS IAM Identity Center (IDC), utilice el flujo de código de dispositivo de AWS Builder ID / IDC desde Panel de control → Proveedores → Kiro → Código de dispositivo. El flujo de código de dispositivo siempre ha estado completamente aislado. No es necesario volver a importar estas conexiones.
Los usuarios empresariales que operan en una región de AWS distinta de la predeterminada pueden especificar la región al importar mediante la API de importación de tokens:
curl -X POST http://localhost:20128/api/oauth/kiro/import \ -H "Content-Type: application/json" \ -d '{"refreshToken": "aorAAAAAG...", "region": "eu-west-1"}'El campo region utiliza us-east-1 de forma predeterminada cuando se omite.
Flujo de importación mediante clave de API
Sección titulada «Flujo de importación mediante clave de API»La autenticación mediante clave de API está destinada a credenciales de portador de larga duración de Kiro / AWS CodeWhisperer. No utiliza la actualización de OAuth, por lo que evita la invalidación de sesiones OIDC compartidas.
Panel de control
Sección titulada «Panel de control»- Abra Panel de control -> Proveedores -> Kiro.
- Seleccione Clave de API.
- Pegue la clave de API y, opcionalmente, la región de AWS (
us-east-1de forma predeterminada). - OmniRoute valida la clave y guarda la conexión.
curl -X POST http://localhost:20128/api/oauth/kiro/api-key \ -H "Content-Type: application/json" \ -d '{"apiKey": "kiro_or_codewhisperer_key", "region": "us-east-1"}'Contrato interno
Sección titulada «Contrato interno»La ruta de la API valida la clave llamando a KiroService.validateApiKey(), que
utiliza ListAvailableProfiles con el endpoint de CodeWhisperer/Amazon Q correspondiente
a la región y resuelve un profileArn.
La conexión guardada utiliza:
{ "authType": "apikey", "providerSpecificData": { "authMethod": "api_key", "region": "us-east-1", "profileArn": "arn:aws:codewhisperer:..." }}Durante la ejecución, KiroExecutor.buildHeaders() envía la clave como
Authorization: Bearer <key> y añade tokentype: API_KEY. Las llamadas de cuota/perfil
utilizan el mismo marcador para que AWS trate el token de portador como una clave de API de larga duración en lugar de
un token de acceso OIDC o social.
Caducidad del cliente OIDC
Sección titulada «Caducidad del cliente OIDC»Los clientes públicos de AWS SSO OIDC suelen caducar después de 90 días
(clientSecretExpiresAt). OmniRoute almacena esta marca de tiempo en providerSpecificData
para facilitar la observabilidad. Si una conexión deja de actualizarse después de aproximadamente 90 días, vuelva a importar la
conexión para obtener un nuevo registro de cliente OIDC. El registro automático de nuevo
al caducar está previsto como una mejora futura.
Las conexiones mediante clave de API no tienen caducidad de cliente OIDC porque no se actualizan a través de AWS SSO OIDC.
Solución de problemas
Sección titulada «Solución de problemas»La segunda cuenta sigue cerrando la sesión
Sección titulada «La segunda cuenta sigue cerrando la sesión»- Compruebe ambas conexiones en Panel de control → Proveedores y confirme que cada una muestre un valor no nulo de
clientIden su JSON sin procesar (visible mediante el icono de información). Si alguna de las conexiones no incluyeclientId, se importó antes de v3.8.0; vuelva a importarla.
La importación falla con “Error de validación del token”
Sección titulada «La importación falla con “Error de validación del token”»- Asegúrese de que el token de actualización comience por
aorAAAAAG. - Asegúrese de que OmniRoute pueda acceder a
https://oidc.us-east-1.amazonaws.com(o a la región configurada). Si se encuentra detrás de un proxy corporativo, configure un proxy a nivel del proveedor en Panel de control → Configuración → Proxies.
La importación mediante clave de API falla
Sección titulada «La importación mediante clave de API falla»- Confirme que la clave sea una clave de API de Kiro / CodeWhisperer, no un token de actualización.
- Confirme que la región de AWS corresponda a la clave/cuenta.
us-east-1es el valor predeterminado. - La clave debe poder llamar a
ListAvailableProfiles; de lo contrario, OmniRoute no podrá resolver elprofileArnrequerido.
Para otros problemas, consulte el archivo principal TROUBLESHOOTING.md.
HagiCode
HagiCode es un espacio de trabajo de programación con agentes, flujos estructurados, ejecución multiagente y vistas de Hero Dungeon.
Convierte ideas en software útil con un flujo de trabajo con agentes más inteligente, rápido y ameno.

- SmartLos flujos estructurados convierten la intención en un itinerario ejecutable desde la idea hasta la entrega.
- EfficientLos flujos multiagente permiten avanzar en paralelo con la investigación, implementación y revisión.
- FunHero Dungeon hace que las largas sesiones de programación sean visuales y colaborativas.