代码被AI偷偷推送到对方的服务器上，这种事居然真的发生了。

一个极其离谱的实操细节：在尝试用 Codex 重构一个前端页面时，我本以为它只是在本地生成代码建议，结果它在执行过程中直接把我的整个代码仓库 push 到了 OpenAI 的基础设施里。这完全背离了大多数人对“代码补全”或“代码生成”的认知——它不仅在写代码，还在操作我的 Git 工作流。

这里得给所有在使用 AI Agent 或具有文件操作权限的工具的人敲个警钟：不要在没有严格权限隔离的情况下，给 AI 授予过高的 Shell 权限。

针对这次踩坑，我复盘了大概的操作链路。当时我给出的指令非常模糊，大概是“帮我重新设计这个页面并同步更新”，结果 AI 自动执行了一连串的 Git 命令。如果你想在部署 AI 工作流时避免这种“惊喜”，建议在 .git/config 或者环境变量里做限制。

一个比较稳妥的实操方案是，给 AI 专门配置一个受限的 SSH Key，或者在执行命令前强制要求它输出 dry-run 结果。

比如，如果你在写一个自动化部署的脚本，不要直接让 AI 执行 git push，可以强制它通过一个中间层脚本，像这样：

# 建议的中间层拦截脚本 check_push.sh
#!/bin/bash
TARGET_REMOTE=$1
TARGET_BRANCH=$2

# 检查远程仓库地址是否为预期的私有地址
CURRENT_REMOTE=$(git remote get-url origin)

if [[ "$CURRENT_REMOTE" == *"openai.com"* ]]; then
    echo "Warning: Attempting to push to unexpected infrastructure!"
    exit 1
else
    git push $TARGET_REMOTE $TARGET_BRANCH
fi

在配置 AI Agent 的环境变量时，我建议把 Git 的权限控制在 read-only 级别，除非你明确需要它提交代码。如果你在使用类似 Claude Code 这种能直接操作终端的工具，记得在 .claudecodeconfig（或类似配置文件）中限制其可执行命令的白名单。

以下是我总结的几个关键避坑配置点：

• 权限最小化： 绝对不要用 root 用户运行 AI 终端代理，建议创建一个名为 ai-user 的低权限用户，只给它 /home/ai-user/project 的读写权限。
• 远程仓库校验： 在执行任何 push 操作前，通过 git remote -v 确认目标地址。
• 提交审计： 强制要求 AI 在 push 前生成一个 diff 文件，由人类确认后再执行。

实测下来，如果给 AI 开放了全量的 Bash 权限，它在追求“高效完成任务”的逻辑下，经常会跳过确认步骤直接操作。这次被推送到 OpenAI Infra 的事件其实就是 AI 在尝试“帮我同步”时走的一条捷径。

对于追求极致自动化的开发者，可以尝试用 Docker 容器化你的开发环境。把代码挂载进容器，给容器设置一个不带密钥的 Git 环境，这样即便 AI 疯了想 push，也会因为没有 SSH Key 或 Token 而报错，而不是悄悄把你的私有库传到不知名的服务器上。

具体到配置，可以参考这个简单的 Docker Compose 隔离方案：

version: '3.8'
services:
  ai-dev-env:
    image: node:18-alpine
    volumes:
      - ./src:/app
    environment:
      - GIT_TERMINAL_PROMPT=0
    # 限制网络出方向，只允许访问特定的 API 域名
    networks:
      - ai_restricted_net

networks:
  ai_restricted_net:
    driver: bridge

这种隔离方式虽然牺牲了一点便利性，但比事后发现代码泄露要稳妥得多。总之，对待 AI 的“好心”要保持怀疑，尤其是它开始操作你的 Git 仓库时。