开发者工具原本应该是效率的翅膀，但7月13日凌晨，xAI的Grok CLI却成为了一只暗藏钩子的信天翁。安全研究者发现，这一官方发布的npm包（@xai-official/grok 0.2.93版）在每轮任务前后，会悄然将整个当前工作目录打包为before_codebase.tar.gz和after_codebase.tar.gz，并通过一个独立旁路通道，静默上传至xAI的Google Cloud仓库。

这一行为的恶劣之处，远超此前围绕Claude Code的“隐形标记”争议。Claude Code仅在输出文本中添加水印，而Grok CLI是实打实地搬运代码——即便模型仅回复一个“OK”，上传动作依然执行。更令人警觉的是，上传的tar包不仅包含仓库文件，还囊括了~/.claude.json、Claude Code的设置数据、全局AGENTS规则、30多个Skill文件，以及一个未被披露用途的API密钥。这意味着，如果开发者正在开发涉及商业机密的项目，其私密配置、第三方服务凭据等核心资产已全部暴露在xAI的服务器上。

从技术架构看，这一旁路通道并非“疏忽”，而是被有意设计为默认开启行为。xAI在7月13日凌晨通过服务端远程开关新增了disable_codebase_upload字段，将默认上传行为强制关闭。但这前后反转的逻辑，恰恰暴露了产品设计中的信任漏洞：一个以“辅助开发”为卖点的工具，为何在一开始就将代码库的上传权限设为默认打开？外部监管滞后、用户毫不知情，这是比恶意软件本身更令人警惕的供应链风险。

我们将此事与Claude Code的隐形标记进行对比：Claude的“小动作”更多停留在输出层，其性质是数据归属标记；而xAI直接触碰用户输入层，将开发者的工作环境视为可巡视的领地。从隐私保护与数据主权的角度看，Grok CLI的行为已经跨过了不可逆的边界。安全社区对此反应强烈，建议所有开发者立即检查并卸载该工具，同时审查本地git历史与第三方服务密钥是否已被泄露。

这场危机给行业带来的警示是：云端优先的AI厂商正逐步将“透明度”让位于“便利性”。开发者不能仅因为工具来自明星公司就放松警惕，必须将安装新工具纳入隐私审查流程，尤其是那些需要文件系统读写权限的CLI应用。未来，类似Grok CLI的静默上传争议或将推动行业标准进一步明确——AI助手到底应该“在本地运行”，还是“在本地窃听”？这个问题，xAI欠所有开发者一个正式的解释。