[Bug]: Antigravity turns fail on NixOS: embedded Python can't verify TLS (empty CA store) -> 502
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- backend
调研方向
从 apps/server 开始，Antigravity ACP 运行时在此被生成 —— 搜索那里已有的 env 整理逻辑（ANTIGRAVITY_HARNESS_PATH、GEMINI_HOME、extendEnv: false）。阅读该生成位置，了解每个进程的环境变量是如何构建的，然后仅在用户未设置且所列 Linux 打包之一存在时才添加 SSL_CERT_FILE（或 SSL_CERT_DIR）。完成的标准是：在内置 CA 路径为空的情况下，prompt 能通过代理成功执行，而用户提供的 CA 变量仍然优先生效；用 NixOS 复现来验证，或在 ACP 生成周围的现有测试中断言所构建的 env。
由索引模型根据 Issue 内容生成。
描述
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
- 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). - Start a thread with any Gemini model and send any prompt.
- The turn never produces output:
session/promptstays 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).
- 主要语言
- TypeScript
- 星标
- 24.8k
- 派生
- 6.4k
- 平均合并
- 8 小时 34 分钟
- 30 天内合并 PR
- 243
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
pingdotgg/t3code 的其他 Issue
-
[Bug]: Dead-key apostrophe inserts extra quotes in the composer可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug via-triage
难度 2/5 1-3 小时 新手友好度 82/100
pingdotgg/t3code#16859 · 1 条评论 ·
维护者通常 1 天内回复
-
bug via-triage
难度 2/5 1-3 小时 新手友好度 72/100
pingdotgg/t3code#16822 · 1 条评论 ·
维护者通常 1 天内回复
-
bug via-triage
难度 2/5 1-3 小时 新手友好度 72/100
pingdotgg/t3code#16821 · 1 条评论 ·
维护者通常 1 天内回复
-
bug via-triage
难度 2/5 1-3 小时 新手友好度 66/100
pingdotgg/t3code#16810 · 2 条评论 ·
维护者通常 1 天内回复
-
bug via-triage
难度 2/5 1-3 小时 新手友好度 62/100
pingdotgg/t3code#16737 · 1 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
DB-plane provider_chat_options.* is accepted by config set but never merged into the loaded config未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
Bump Firebase JS SDK (12.19.0 → 13.0.0)可能已有人在做 @SelaseKay 今天认领。 未关闭Needs Attention type: enhancement
难度 2/5 1-3 小时 新手友好度 75/100
invertase/react-native-firebase#9364 · 1 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 1/5 1 小时以内 新手友好度 85/100
cloudflare/mcp#271 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 4 天内回复
-
e2e-failure ready-to-code
难度 2/5 1-3 小时 新手友好度 78/100
redhat-developer/rhdh-plugin-export-overlays#4261 · 1 条评论 ·
维护者通常 1 天内回复