Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug]: Antigravity turns fail on NixOS: embedded Python can't verify TLS (empty CA store) -> 502

Abierto Apto para principiantes
  • ¿Algo no está bien?
#16,742 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@felixlaga ya está trabajando en esto.

Desde el 17/10/2026.

  • #20551 de @felixlaga — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

Empieza en apps/server, donde se instancia el runtime ACP de Antigravity — busca la curación de env ya realizada allí (ANTIGRAVITY_HARNESS_PATH, GEMINI_HOME, extendEnv: false). Lee ese sitio de spawn para ver cómo se construyen las variables de entorno por proceso y luego añade SSL_CERT_FILE (o SSL_CERT_DIR) solo cuando el usuario no las haya definido y exista uno de los bundles de Linux listados. El resultado esperado es: los prompts funcionan detrás del proxy con una ruta CA integrada vacía, y las variables CA proporcionadas por el usuario siguen teniendo prioridad; verifica con la repro de NixOS o afirmando el env construido en los tests existentes alrededor del spawn del ACP.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug via-triage
Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server

Steps to reproduce
  1. On NixOS (any distro without the CA paths the bundled Python expects), install T3 Code and set up Google Antigravity (oauth-personal) with the managed ACP runtime (1.3.0).
  2. Start a thread with any Gemini model and send any prompt.
  3. The turn never produces output: session/prompt stays open until cancelled, or the turn ends with the raw text below.
Expected behavior

The agent establishes TLS to the CCPA API using the system trust store (or an env-provided CA bundle) and answers normally.

Actual behavior

Every TLS handshake from the embedded Python fails:

E1007 00:57:44.712115 proxy_server.py:222] Proxy failed to connect to CCPA API:
Network connection failed to CCPA API: [SSL: CERTIFICATE_VERIFY_FAILED]
CERTIFICATE_VERIFY_FAILED: unable to get local issuer certificate (_ssl.c:1104)
...
File ".../acp_server/ccpa_connection/ccpa_client.py", line 173, in stream_generate_content
    res = urllib.request.urlopen(req, timeout=_DEFAULT_TIMEOUT_SECONDS)

(from agy_acp_server.par.*.log.ERROR; ccpa_client.stream_generate_content
uses urllib with the default SSL context). The local proxy converts that into
502 Failed to connect to backend API, so the user-visible symptom is identical
to #16010 — but the disease is different: the agent can never open TLS at all
here, not a transient upstream reset. curl, the agy CLI, and system Python
reach Google's APIs fine from the same machine; only agy_acp_server.par fails,
because its baked-in CA default paths don't exist on NixOS and its trust store
ends up effectively empty.

Impact

Blocks work completely

Version or commit

v0.0.46-nightly.20261006.2752

Environment

Linux x86_64 (NixOS 25.05), T3 Code Desktop, Provider: Google Antigravity (ACP) 1.3.0, oauth-personal. Models tried: gemini-3.8-flash-low, gemini-3.8-flash-medium (identical failure).

Logs or stack traces

Full traceback (proxy_server.py:222 → ccpa_client.py:196 → urllib →
ssl.SSLCertVerificationError) available in the agent glog quoted above.
No tokens or credentials involved — the failure happens before any auth header
is sent.

Suggested fix

T3 already curates the agent environment (GEMINI_HOME, per-process TMPDIR,
ANTIGRAVITY_HARNESS_PATH, AGY_ACP_FORCE_FILE_STORAGE, extendEnv: false).
On Linux, set SSL_CERT_FILE (or SSL_CERT_DIR) from the first existing
well-known system bundle when spawning the Antigravity runtime:

  • /etc/ssl/certs/ca-bundle.crt
  • /etc/ssl/certs/ca-certificates.crt
  • /etc/pki/tls/certs/ca-bundle.crt

Verified locally: launching the same binary with SSL_CERT_FILE pointed at the
system bundle (which the embedded CPython honors) makes prompts succeed
immediately — same account, model, and machine. Only apply when the user hasn't
set SSL_CERT_FILE/SSL_CERT_DIR themselves, so custom CAs and TLS-inspecting
proxies keep working (cf. #16703).

Workaround

Point the Antigravity instance's Binary path at a wrapper that exports
SSL_CERT_FILE before exec'ing the managed agy_acp_server.par.

Relationship to #16010

Same user-visible symptom (502 / model unreachable), different root cause:
#16010 is transient upstream resets killing an already-running turn; this is
the agent never being able to open TLS on distros without the expected CA
paths. Linking for visibility; happy to split or merge as maintainers prefer.

Related TLS-trust handling: #16703 (different subsystem — T3's own GitHub sync).

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
2 h 31 min
PR fusionados (30 d)
475

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.