[EzequielKoulaksezian]

Related issue / Issue relacionada

Issue: #237 (avance parcial; esta PR no la cierra)
ODD: no aplica

Scope / Alcance

Diagnóstico y preparación para leer la cuota de Antigravity desde el agy CLI en macOS, con manejo seguro de la limitación encontrada. No agrega soporte funcional del CLI en macOS: su language server exige un token CSRF que el CLI no expone, y no se pudo leer ninguna cuota real.

• Lo que se comprobó. En macOS el agy CLI escribe ~/.gemini/antigravity-cli/log/cli-YYYYMMDD_HHMMSS.log (uno por sesión), con el PID del language server y su puerto HTTP. POST …/GetUserStatus contra ese servidor (language server 1.4.12) responde HTTP 401 unauthenticated: missing CSRF token sin header y con el header vacío. El proceso del log tiene comm=agy y su línea de comandos es solo agy: no trae --csrf_token.
• IDE de escritorio primero. En macOS, find_server() mantiene la detección por ps (language_server + --app_data_dir antigravity + --csrf_token) con el log ~/Library/Application Support/Antigravity/logs/language_server.log. Windows y Linux no cambian.
• Alternativa del CLI, solo si es segura. Se recorren los cli-*.log del más reciente al más antiguo. Un log sirve si su último PID sigue vivo, ps -p <pid> -o comm= es language_server… o agy, y los argumentos traen --csrf_token. Nunca se envía un token vacío ni se consulta un PID reutilizado.
• Proceso, log y puerto vinculados. El servidor elegido conserva el puerto HTTP del mismo log que lo identificó. Ya no se vuelve a buscar el PID en otros logs, donde un PID reutilizado podía apuntar a un puerto obsoleto.
• Textos. El README y Ajustes (kicker «IDE de escritorio», openBody) dicen que la sesión del CLI de macOS no se puede leer porque no expone el token. El inventario i18n se regeneró con node scripts/i18n-inventory.mjs.

Pending / Pendiente

• Lectura real de cuota desde el agy CLI en macOS. Depende de que el CLI exponga el token CSRF (o de otra vía de autenticación). Hasta entonces Antigravity (agy CLI): not working on macOS — wrong log path and process detection #237 sigue abierta.

Coordination / Coordinación

• N/A (no aplica ODD)

Contributor / Contribuidor: @EzequielKoulaksezian

Acceptance and validation / Aceptación y validación

• Criteria satisfied / Criterios cumplidos:
  • La detección del IDE de escritorio en macOS tiene prioridad sobre el log del CLI.
  • La alternativa del CLI exige el proceso correcto y --csrf_token. Sin token no consulta.
  • El puerto consultado es el del log que identificó el servidor.
  • No se anuncia soporte del CLI de macOS.
• Checks actually run and results / Comprobaciones ejecutadas y resultados (macOS arm64, local):
  • cargo fmt --all -- --check: OK.
  • cargo test --locked: 410 passed, 0 failed, 1 ignored (23 de providers::antigravity, incluida la regresión port_comes_from_the_log_that_selected_the_server).
  • node scripts/i18n-inventory.mjs --check: OK.
  • Prueba manual del endpoint del agy CLI: 401 missing CSRF token, como se describe arriba.
• Checks not run and why / Comprobaciones no ejecutadas y motivo:
  • CI de GitHub: los workflows de esta PR quedan en action_required porque viene de un fork y necesitan la aprobación de un mantenedor para correr.
  • Builds de Windows y Linux: no hay toolchains de esos targets en local; los cubre la CI.
  • Lectura real de cuota en macOS: bloqueada por el token CSRF (ver Pendiente).
• Remaining blockers / Bloqueos pendientes:
  • Aprobación de los workflows de CI sobre el head final.
  • Soporte funcional del CLI en macOS, fuera del alcance de esta PR.

[egdev6]

Gracias por la PR, @EzequielKoulaksezian. El enfoque tiene sentido, pero antes de integrarla hacen falta varios ajustes. Revisé 478afac:

1. Evidencia de punta a punta en macOS. La PR no muestra ninguna cuota leída realmente en macOS. Además, envía el token CSRF vacío: la propia Antigravity (agy CLI): not working on macOS — wrong log path and process detection #237 indica que hay que confirmar si el endpoint lo exige, pero el comentario del código afirma que no hace falta, y el README y los textos de Ajustes ya anuncian soporte. Necesito una lectura real (captura o log saneado del orbe con la cuota) y la confirmación del comportamiento del endpoint sin token. Si lo exige, hay que resolverlo antes de anunciar soporte.

2. No sustituir la detección del IDE de escritorio en macOS. El cambio reemplaza por completo log_path() y find_server() en macOS, así que quien use la app de Antigravity en Mac podría perder la detección. Propongo intentar primero la detección actual del IDE y usar el log del agy CLI solo como alternativa.

3. PID tomado del log. Con kill -0 sobre el PID del log más reciente, un log antiguo con un PID reutilizado haría consultar un puerto obsoleto. Conviene comprobar que el proceso con ese PID es realmente el language server (por ejemplo, su ejecutable con ps -p <pid> -o comm=) antes de usarlo.

4. La CI va a fallar por dos motivos que comprobé:

   • docs/i18n-inventory.md está editado a mano y los hashes del encabezado no coinciden con lo que genera el script. Ejecuta node scripts/i18n-inventory.mjs y añade el resultado en un commit aparte; no se edita a mano.
   • Hay una línea en blanco doble antes de la nueva find_server() de macOS, que cargo fmt --check rechaza.

5. Detalles menores:

   • latest_server_pid solo se usa en macOS; en Windows/Linux fuera de los tests generará un aviso de código muerto. Puedes limitarla con #[cfg(any(target_os = "macos", test))].
   • El comentario de log_path() para Linux menciona el agy CLI sin verificarlo.
   • En Ajustes, kicker («IDE abierto») y openBody siguen hablando solo del IDE abierto.

Como no tienes toolchain de Rust en local, la CI se encargará de cargo test y rustfmt cuando la PR esté lista. ¡Gracias por el trabajo!

[EzequielKoulaksezian]

Apliqué la revisión sobre 478afac. La rama queda en a53a53f.

1. CSRF y soporte anunciado. Confirmé el endpoint local de un agy CLI en marcha (language server 1.4.12). POST /exa.language_server_pb.LanguageServerService/GetUserStatus sin header y con X-Codeium-Csrf-Token vacío responden los dos HTTP 401 unauthenticated: missing CSRF token. El proceso del log tiene comm=agy y la línea de comandos es solo agy: no hay --csrf_token. El log trae el PID y el puerto HTTP, y no menciona el token. No pude leer una cuota real, así que el README y Ajustes ya no anuncian soporte del CLI en macOS. Dicen que esa sesión no se puede leer porque el token no está expuesto.

2. El IDE de escritorio sigue primero. En macOS, find_server() usa la detección por ps (language_server + --app_data_dir antigravity + --csrf_token) y el log ~/Library/Application Support/Antigravity/logs/language_server.log. El log ~/.gemini/antigravity-cli/log/cli-*.log queda solo como alternativa.

3. PID del log. Esa alternativa exige ps -p <pid> -o comm= (language_server… o agy) y --csrf_token en los argumentos. Un PID reutilizado, o agy sin token, no se consulta. Hay un test para esos dos casos.

4. CI. Saqué la línea en blanco doble. cargo fmt quedó aplicado y cargo test --lib providers::antigravity::tests pasó: 22 tests. El inventario se regeneró con node scripts/i18n-inventory.mjs en el commit aparte a53a53f, y --check pasa en ese commit.

5. Detalles. latest_server_pid está en #[cfg(any(target_os = "macos", test))]. El comentario del log de Linux ya no habla del agy CLI. En Ajustes, kicker pasa a «IDE de escritorio» y openBody explica que el CLI de macOS no se puede leer.

Queda pendiente una lectura real de cuota el día que el CLI publique el token. Hasta entonces no doy por cerrado el soporte de macOS.

[egdev6]

Gracias por la aportación y por investigar el comportamiento real del endpoint, @EzequielKoulaksezian. Confirmar el 401 por falta de CSRF y retirar el anuncio de soporte evita prometer una integración que todavía no funciona. Revisé a53a53f: la detección del IDE vuelve a tener prioridad, el fallback exige token y comprobé que el inventario coincide con el generador.

Para poder aprobar esta PR como avance parcial, quedan estos puntos:

1. Vincular proceso, log y puerto en la misma detección. Actualmente find_server() selecciona un proceso usando un log del CLI, pero http_port_for(pid) vuelve a buscar el PID primero en el log del IDE y luego en todos los del CLI. Si un log antiguo contiene ese mismo PID reutilizado, puede devolver un puerto que no corresponde al servidor seleccionado. Conserva el puerto del log usado para detectar ese servidor —o su procedencia— y añade una regresión con dos logs que contengan el mismo PID y puertos distintos, comprobando que se consulta el del servidor seleccionado.

2. Actualizar título, descripción y relación con Antigravity (agy CLI): not working on macOS — wrong log path and process detection #237. Todavía anuncian soporte macOS y ausencia de bloqueos, aunque la prueba real confirmó que el CLI no expone el token requerido y no se pudo leer ninguna cuota. Presenta esta entrega como diagnóstico/preparación y manejo seguro de esa limitación, explicita lo pendiente y evita cerrar Antigravity (agy CLI): not working on macOS — wrong log path and process detection #237 mediante esta PR. No pedimos una cuota real para aprobar ese alcance parcial; sí será necesaria para dar por resuelto el soporte.

3. Checks de CI sobre el head final. Por ahora no aparecen checks en a53a53f. Gracias por informar los 22 tests locales; antes de aprobar necesitamos los checks aplicables en verde sobre el commit final, incluyendo formato, tests y builds de las plataformas afectadas.

Mi comprobación fue estática y del inventario generado; no ejecuté Rust ni validé la app nativa en macOS. ¡Gracias por continuar el trabajo y documentar con claridad la limitación encontrada!

[EzequielKoulaksezian]

Apliqué la revisión sobre a53a53f. La rama queda en 256c061.

1. Proceso, log y puerto vinculados. Server guarda el puerto HTTP del mismo log del CLI que identificó el proceso. http_port_for ya no existe: el servidor del CLI usa ese puerto y el del IDE sigue leyendo language_server.log. La regresión port_comes_from_the_log_that_selected_the_server usa dos logs del CLI con el mismo PID y puertos distintos, más un log del IDE que también lo repite, y comprueba que se consulta el puerto del log elegido.

2. Título, descripción y Antigravity (agy CLI): not working on macOS — wrong log path and process detection #237. La PR queda presentada como diagnóstico y preparación, con la limitación del token CSRF y lo pendiente explícitos. Ya no cierra Antigravity (agy CLI): not working on macOS — wrong log path and process detection #237.

3. CI. En local (macOS arm64) sobre 256c061: cargo fmt --all -- --check OK, cargo test --locked 410 passed y 1 ignored, node scripts/i18n-inventory.mjs --check OK. Los workflows de la PR (CI, macOS CI, Linux PR CI, Code safety, Security) están en action_required porque viene de un fork. Hace falta que los apruebes para que corran sobre este head.

[egdev6]

Gracias por la aportación y por atender las revisiones, @EzequielKoulaksezian. Doy el visto bueno a la aportación con el alcance parcial que ahora describe la PR: diagnóstico y preparación del agy CLI en macOS, sin anunciar soporte funcional ni cerrar #237.

Me encargo de lo que quede pendiente para dejarla lista para integrar. Ya corregí el inventario en 07f2029 y autoricé los cinco workflows; estoy siguiendo sus resultados. No necesitas hacer más cambios por ahora: si aparece algún ajuste final, lo resuelvo yo.

La lectura real de cuota del CLI sigue pendiente del token CSRF y queda recogida en #237. Este visto bueno a la aportación no significa que la CI haya terminado ni que el soporte macOS esté resuelto. ¡Gracias por el trabajo y por documentar la limitación con claridad!