ChatGPT网页版逆向API在Codex中无法修改文件求助

背景

随着 OpenAI 不断收紧 ChatGPT 的 API 访问限制，一些开发者转向使用开源项目如 chatgpt2api 将 ChatGPT 网页版（Web 版）逆向工程为可调用的 API 接口，从而绕过官方 API 的计费或配额限制。这类逆向方案通常只模拟了对话模型的文本生成能力，不包含额外的工具调用或文件操作功能。与此同时，OpenAI 的 Codex（代码生成与执行环境）或类似 IDE（如 Cursor、Replit）期望模型具备读写文件、执行系统命令等能力，以完成自动化编程任务。这种能力缺口导致用户在使用逆向 API 时遇到“无法修改文件”的困境，并寻求通过 skill、MCP（Model Context Protocol）、tools 等扩展机制来弥补。

核心内容

原文出自 LINUX DO 论坛的 AI 技能/提示词/工作流分享板块，标题为“我使用chatgpt2api逆向了gpt网页版，在codex中无法修改文件，有没有解决办法”。用户描述：

• 使用 chatgpt2api 项目将 ChatGPT 网页版（免费版或付费版）反向工程为兼容 OpenAI API 格式的接口。
• 在 Codex（这里可能指 OpenAI Codex Playground 或类似代码编辑环境，如 Cursor 内置的 Codex 功能）中调用该逆向 API，但发现模型无法执行文件修改操作（如创建、写入、编辑、删除文件）。
• 用户理解逆向得到的只是纯对话模型（dialogue model），不具备文件系统交互能力。
• 询问是否存在可用的 skill、MCP、tools 或其他方法，能让该逆向 API 在 Codex 中获得文件修改能力。

论坛共有 3 个帖子、3 位参与者，原文未给出具体回复内容，因此本解读仅基于提问本身。

关键要点

• 逆向 API 的功能限制：chatgpt2api 仅模拟了 ChatGPT 网页版的对话接口，不包含任何工具调用（如代码解释器、文件读写、网络请求）的代理逻辑。官方 API 的 functions 或 tools 参数在逆向 API 中通常不被支持，因为网页版本身不暴露这些接口。
• Codex 环境的文件操作需求：Codex 或类似 IDE 依赖模型通过 file_read、file_write 等自定义函数来与本地或云端文件系统交互。若模型本身不具备这些能力，则无法完成编辑任务。
• 可能的解决方案方向：
  • 在逆向 API 与 Codex 之间增加一个中间层，将 Codex 发起的文件操作请求转换为 ChatGPT 对话中的自然语言指令，再由中间层解析并执行文件操作（例如，通过一个本地代理监听 Codex 的调用，将文件操作转为系统命令）。
  • 使用 MCP（Model Context Protocol）——一种让模型与外部工具交互的协议——来封装文件操作工具，并让逆向 API 通过 MCP 客户端调用这些工具。
  • 寻找已有 skill 或插件，例如 Open Interpreter、Code Interpreter API 的逆向实现，或使用 gpt4free 等更全面的逆向项目，这些可能包含工具调用支持。
  • 直接使用官方 API 的 Code Interpreter（GPT-4 with Code Interpreter）或 Azure OpenAI 的托管服务，但需付费。

意义与影响

1. 揭示逆向工程与功能完整性的矛盾：chatgpt2api 类项目降低了 AI 使用成本，但牺牲了模型的多模态和工具调用能力。这一矛盾在需要代码执行、文件操作的专业场景中尤为突出，提醒开发者不应期望免费逆向方案能完全替代官方 API。

2. 推动社区开发中间件与适配层：该提问直接指向一个客观需求——为逆向 API 添加文件操作能力。未来可能出现更多类似 chatgpt2api-file-tools 或 MCP bridge for chatgpt2api 的开源项目，将对话模型与本地文件系统桥接。

3. 对 Codex 生态的启发：Codex 类工具在设计时通常假设底层模型支持函数调用，逆向 API 的流行可能促使 Codex 客户端增加“自定义工具提供者”的接口，允许用户手动注入文件操作能力，而不依赖模型原生支持。

4. 安全与合规考量：逆向 ChatGPT 网页版违反 OpenAI 服务条款，且可能面临封号风险。同时，赋予逆向 API 文件操作能力会增加安全风险（如恶意代码执行）。社区在提供解决方案时需同步标注法律和安全性警告。