安全研究员指控 Sarvam Code：Codex CLI fork 剥离署名，被包装成"主权 AI"

8 月 27 日 07:52（UTC），印度安全研究员 nisarga（@ni5arga）在 X 上点名指控 Sarvam AI 的编程智能体 Sarvam Code："be sarvam, fork @OpenAI's apache-2.0 licensed open source code, strip the attribution, call it sovereign ai. incredible engineering. these are our frontier labs man."（当 Sarvam 吧：fork OpenAI 的 Apache-2.0 开源代码，剥掉署名，再叫它主权 AI。了不起的工程。这就是我们的前沿实验室。）截至本稿核验时，这条帖子浏览量已超过 8.4 万，获约 1,550 个赞、100 多次转发。

nisarga 在简介中自称 19 岁、软件工程师、黑客与安全研究员（hacker & sec researcher），近期的公开帖子包括对 CERT-In 漏洞处理流程和印度创业公司安全问题的批评。"fork"这一半几乎没有争议：Sarvam 自己在中写道，"The harness builds on Codex"（框架构建在 Codex 之上）。真正悬而未决的，是"剥掉署名"这一半。

「fork 掉署名，再叫它 sovereign ai」

帖子发出后，评论区迅速分成两派。开发者 Manash（@KitsuneKode）开源本来就是拿来构建的，"这不是偷，与其从 0 开始，不如站在已经做到 70 分的东西上"；nisarga 只回了一句："stripping the attribution = stealing. as simple as that."（剥掉署名就是偷，就这么简单），获得 88 个赞。当 praveeninfo17 拿 Cursor、Windsurf 都是微软 VS Code 的 fork 来时，nisarga 的是："none of them are violating the original license terms, learn how to read"（它们没有一个违反原许可证条款）。

上午 10:53，他把矛头扩大到其他印度项目："别忘了 BharOS fork GrapheneOS、ShaktiDB fork Postgres、Ping Browser fork Brave——三者都是以非常阴暗、不诚实、不透明的方式做的。"又获得 254 个赞。他的立场贯穿始终：开源代码可以用，但用了不能说成自己的。

7 月 30 日就有人贴出 fork 证据

nisarga 不是第一个指出 Sarvam Code 血统的人。7 月 30 日，即 Sarvam Code 在首届 Epoch 大会（7 月底于班加罗尔举行）发布后不久，开发者 cheaty（@cheatyyyy）就称"Sarvam Code is a fork of OpenAI's Codex CLI!"并附证据截图，这条帖子累计超过 14 万次浏览。当天 @jst_kishan 跑通 Sarvam Code 图形界面后同样："it is a fork of codex cli, with a gui"。

随后是两份更系统的分析。IIT Bombay 校友、在 @evo__hq（YC F26）工作的 Alok Bishoyi 从二进制层面，Sarvam Code 是"OpenAI Codex 的下游私有发行版"——原生核心与 Codex 共享协议方法、crate 结构、消息与配置行为、工具语义，Sarvam 换掉了产品表面、接上自家网关，再叠加 goals、guardian review、记忆、递归执行、文档处理等能力。Ojasvi Yadav 的则逐项列出指纹：exec、resume、fork、mcp 等命令面与 Codex CLI 完全一致；沙箱三档 read-only / workspace-write / danger-full-access、审批策略 untrusted / on-failure / on-request / never 均与 Codex 相同；--dangerously-bypass-approvals-and-sandbox 这个绕过旗标逐字一致；二进制里还残留着未清理的 x-openai-subagent 字符串。

拆解结论是：Sarvam 改了身份与系统提示词（"You are Sarvam Code, an autonomous software-engineering agent"），把端点换成 Sarvam 网关，并加上文档 OCR、Guardian 审批、RLM 递归模式等自家功能；下载校验和与 Sarvam 官方发布值完全一致。

Sarvam 官方口径与这些外部分析一致：Epoch 回顾在介绍 Sarvam Code 时写明"框架构建在 Codex 之上"，同时强调它按"完成任务成本"优化，在 100B、700B、3T 三档模型间路由，可部署在印度境内、客户 VPC 或本地。

「主权 AI」叙事，和它背上的生意

争议之所以比一次普通套壳更刺眼，在于 Sarvam 的公开定位就是"主权 AI"。其简介写着"Building the bedrock of Sovereign AI for India"（为印度建设主权 AI 的基石），粉丝 8.4 万。称，联合创始人 Vivek Raghavan 把公司方向概括为"token sovereignty"（token 主权）——让印度消费的 AI token 更多由境内基础设施服务，而不是海外云厂商。

这套叙事背后是实打实的政府与资本生意。泰米尔纳德邦政府 1 月 13 日与 Sarvam ，建设印度首个全栈 Sovereign AI Park，初期投资 1 万亿卢比（₹10,000 crore），预计创造约 1,000 个高级岗位；联合创始人 Pratyush Kumar 当时称，"现在我们依赖外国模型，把数据出口、把人工智能进口，这既不可持续也不可取"。

MediaNama 还报道，印度中央政府 IndiaAI 计划已选定 Sarvam 承担国家主权大语言模型建设，它是 67 家申请者中第一家拿到资金的。8 月初， Sarvam 正为其 3 亿美元 B 轮追加 7,400 万美元，参投方包括 NVIDIA、Glade Brook、Gaja Capital、Indigo Ventures，资金用于"建设全栈主权 AI 生态"。

Sarvam Code 是这套叙事的最新一块拼图：Inc42 称它面向软件开发、机器学习与网络安全工作流，用 planner、worker、verifier 三类 agent 执行编码任务，以早期 beta 形式在 Indus 平台下分发；Kumar 在"同样的任务在 Sarvam Code 上解决会更便宜"。而 nisarga 的嘲讽正是冲着这个组合拳来的：一个 Apache-2.0 的 fork，顶着"主权 AI"的旗号，讲着国家算力自主的故事。

Apache-2.0 允许 fork，争论焦点在署名

许可证层面没有分歧：OpenAI 的（GitHub 11.9 万 star）明确标注 Apache-2.0 许可。X 账号 AGTP 在中称，OpenAI 于 7 月 29 日以 Apache-2.0 开源 Codex CLI，该许可允许复用与修改，但要求保留版权与许可声明。因此 Kumar Priyanshu 辩护者："fork 没有错，但你仍然必须遵守每个项目的许可证，不能把 Apache-2.0 项目当 MIT 用。"EdwinCh 更直接："Apache-2.0 让你 fork，保留署名行本来是最不需要成本的部分。"

辩护方则强调两点。其一，开源生态本来就在 fork 上生长：praveeninfo17 举出 Cursor、Windsurf 之于 VS Code 的先例，Mainak Mukherjee 也"主权不代表从零开始"。

其二，CLI 不等于模型：Prakhar Pandey "Sarvam Code 这类 CLI 工具与底层的 sovereign ai 模型是两回事，CLI 是 fork 并不能证明模型不是他们自己训练的"；EisenVault 创始人 Vipul Swarup 主权应该指"对权重、算力与部署的控制，以及印地语优先的行为"，"何必重新发明轮子"。Amartya Sinha 则把矛盾到包装上："开源就是这样运作的，问题出在品牌上——他们自称 AI 实验室，还拿着巨额融资。"nisarga 对这些的回应始终是同一句：别的 fork 没有违反原许可证条款。

署名之争仍无定论

整场争论的核心问题——Sarvam Code 的分发物里，Apache-2.0 要求的版权与许可声明到底还在不在——目前没有一方给出可直接对照的证据。nisarga 在时给出他的"最终证据"："absence of attribution and the original license which has the openai copyright is the ultimate proof"（署名与含 OpenAI 版权的原许可文件的缺失，就是最终证据），并补了一句"我们都记得 Sarvam 过去对 Mistral 模型做过什么"——后者目前只是他个人的指控。而 Ojasvi Yadav 的拆解显示的是另一面：二进制里残留着未清理的 x-openai-subagent 等上游痕迹，说明代码层并没有彻底"洗白"；报告也没有给出署名文件保留与否的结论。