一些公司网络会拦截 HTTPS（Zscaler 和类似产品）并使用公司 CA 对其进行重新签名。该 CA 在笔记本电脑上是受信任的，但在生成的本地开发镜像中不受信任，因此 uv / npm 在镜像构建期间会因 TLS 信任错误（例如 UnknownIssuer）而失败。
提供公司 CA
将 root 拦截 CA 导出为 PEM。中间证书仅在链不完整时才有用；信任锚点是根证书。典型来源：
您的操作系统信任存储（Keychain /
certmgr//etc/ssl/certs）您的 IT 团队已经记录的导出
将 CLI 指向该文件：
agentengine dev up --ca-bundle /path/to/corp-root.pem
AGENTENGINE_CA_BUNDLE 在进程环境中是等效的。工作区 .env 中的值会被忽略，因此克隆的存储库无法安装 CA。
CLI 会验证 PEM（仅限证书，不含私钥），将其按工作区记录在~/.agentengine/ca-bundles/ 下，并在包安装**之前**将授权副本嵌入到生成的镜像中，然后将其合并到 Amazon Linux 信任包中。构建过程从不从可写工作区读取任何内容，因此运行之间的存储库或容器更改不会改变受信任的内容。存储库附带的 .agentengine/ca-bundle.crt 永远不会被读取；它只会引发警告。
记录的 CA 也应用于运行时，而不仅仅是构建时：生成的镜像将标准 CA 环境变量（SSL_CERT_FILE、REQUESTS_CA_BUNDLE、CURL_CA_BUNDLE、NODE_EXTRA_CA_CERTS 和 uv 的 system-cert 模式）点向合并后的捆绑包，因此代理通过拦截代理进行的 HTTPS 调用也能正常工作。这些变量及其目录选择器同级 SSL_CERT_DIR 由本地堆栈的 CLI 拥有：工作区 .env 中的这些变量的值不会传递给开发容器，因此克隆的存储库无法将工作程序的 TLS 的点设为它附带的证书。如果您需要另一个 CA（示例私有注册表的 CA），请将其添加到您传递给 --ca-bundle 的捆绑包中。
后续 agentengine dev up 运行会重用同一台机器上的记录；不同的机器或检出不会继承它——请在那里再次传递该标志。--clear-ca-bundle 删除记录并重新生成而不包含 CA。
请勿手动编辑 .agentengine/Dockerfile.dev。下一个 agentengine dev up 会重新生成它。
这不会改变什么
未提供 CA 的开发者将获得与之前相同的镜像构建。
没有
--insecure标志。没有受信任 CA 的 TLS 故障仍然会报告信任问题。agentengine二进制文件本身使用的 OS 信任存储（示例AGENTENGINE_IMAGE_SOURCE=custom）是分开的；请按照 custom-artifact-source.md. 中的文档说明，将该 CA 安装在托管上。