很多人以为在中转站后台点一下,Codex 就能自己去改你电脑上的文件。实际上中转站只负责转发模型请求,真正碰到本地磁盘、终端和浏览器的,是你本机那层客户端或 Agent 程序。这篇把这条链路拆开讲:先确认哪一步该配在哪里,再给一套从权限到网络的自查顺序,配完卡住时知道该翻哪一层。
很多人以为在中转站后台点一下,Codex 就能自己去改你电脑上的文件、跑你终端里的命令。实际链路比这长:中转站只替你换掉接口地址和鉴权,请求从你的电脑出发,经过中转站,再转给上游模型,模型回的是「决策」,不是「动作」。真正伸手碰你磁盘、剪贴板和浏览器的是你本机那层客户端或 Agent 程序。把这条链路拆开看,配置才不会配错地方。
这篇不给一套「万能开关」,只给判断标准和可执行动作:先分清哪一步该配在哪一层,再给一套从权限到网络的自查顺序。配完发现不动,按顺序往回退,能少走很多弯路。涉及具体站点、模型和延迟数据,都到站内对应页面核对当时的数字,别拿别人的截图当基准。
先分清:谁碰你的电脑,谁只转发请求
中转站的角色是替换接口基址和密钥,让请求换个出口发出去。它不接触你的本地文件、剪贴板和终端。所以别指望在站点后台勾一个开关就能远程操控你的电脑——那个开关不在它手里。执行本地动作的能力,来自本机运行的那层程序:它把「读了哪个文件、跑了哪条命令、点了页面哪个位置」的结果打包成上下文,再发给模型,模型只负责回下一步该做什么。
有个很直接的判断方法:把中转站地址填进客户端后,如果原本能做的本地动作突然做不了了,说明这个能力本来就在客户端,跟中转站无关;反过来,换了站点之后本地文件的读写还在,说明链路是通的,问题多半出在别处。纯网页版对话这类只能在浏览器里聊天的产品,天生拿不到本地文件权限,换哪家中转站都一样,这一点不用折腾。
- 中转站
- 只做地址替换和请求转发,不碰你的本地资源
- 本机客户端 / Agent
- 真正执行读文件、跑命令、控浏览器的一方,能力开关在这里
- 模型侧
- 只回决策和文本,不下达能直接改你电脑的指令
配置链理顺:地址、鉴权、工具开关三段怎么接
配置分成三段,顺序别反。第一段是把客户端的接口基址和密钥换成中转站给的,换完先用一次普通问答确认连通,别一上来就跑复杂任务,否则出错时分不清是配置问题还是任务本身的问题。第二段是开启客户端里的本地工具能力,文件读写、命令执行、浏览器控制各自独立,按当前任务开,能少开就少开。
- 先通链路在客户端填入中转站基址和密钥,发一句普通对话。能正常回话,说明鉴权和转发都成立,这一步没有本地动作参与。
- 再开工具在客户端设置里勾选需要的本地能力,一次只开一类,比如先只开文件读取,确认状态栏或日志里该能力显示为已启用。
- 最小验证让它读一个你指定的文件并原样回报内容。能读对,再升级到写文件;写文件成功,再试命令执行。
- 逐步升级每次只增加一类能力,每升一级就重跑一次最小任务。哪一级开始失败,问题就在那一级对应的配置上。
第三段才是做真实任务。不少人卡住是因为把顺序做成「先干重活、再回头查配置」,日志里全是工具调用失败,反而看不出根因。按上面四步走,每一步都有独立的成功判据,出问题能定位到具体一层。
权限边界怎么划:给多少、留在哪、怎么收回
能力开出来之后,真正决定风险的是边界划在哪。建议先限定工作目录,只让它在专门建的一个文件夹里活动,跑通再往外扩。直接对整个用户目录或系统盘开放,等于把误删和误改的窗口开到最大。命令执行类能力风险最高,如果客户端支持「先展示命令、人工确认再执行」,优先用这个模式,别默认全自动。
| 能力类型 | 建议先给的范围 | 什么情况下不适用 |
|---|---|---|
| 文件读取 | 单个专用文件夹 | 需要跨盘对照资料时,先复制进目录再开 |
| 文件写入 | 同一专用文件夹 | 多人共用一台机器时,写入范围要按账号隔离 |
| 命令执行 | 先展示后确认 | 需要长时间无人值守的任务,必须另想办法限权 |
| 浏览器控制 | 单独的用户配置或会话 | 涉及已登录的敏感账号,不要交给自动流程 |
还有个容易忽略的点:数据流向。文件内容和命令输出都会作为上下文发给中转站再转上游,所以敏感文件不要放进工作目录。这类隐私和留存的问题,可以到站内相关说明页面对照看当时的规则。团队共用一把密钥时,本地权限和密钥权限是两回事——本地给了权限,等于给了所有拿这把钥匙的人,授权前先想清楚这一点。
不通时的排查顺序:从最近的一层往回退
卡住时最忌讳同时改好几个地方。正确做法是分层回退,每一步只验证一层,确认这层没问题再往下走。下面这套顺序从最靠近你的本地动作出发,逐步退到中转站和网络,能快速分辨是断、是慢,还是根本没配通。
- 只发普通对话不带任何本地工具,发一句普通问题。不通就是站点或密钥问题,本地配置不用查。
- 看实际请求让客户端打印它发出的请求地址和状态码。连不上、鉴权失败、模型侧报错,三种情况的处理方向完全不同。
- 试最轻的本地动作单独试一个列目录之类的轻动作。这一步失败,说明工具调用被拦或客户端没启用该能力,跟站点无关。
- 量一次延迟基线用站内的测速工具跑一次,到站内测速页面看当时的数字。是慢还是断,决定你该换站点还是查本地。
- 留档对照把每次的请求地址、状态码和报错原文记下来。换站点或换客户端时直接对照,不用从头再猜一遍。
这套顺序也适用于日常维护:换了一个新中转站、升级了一次客户端、动过一次权限设置,都按同样的顺序重跑一遍最小任务,比等大任务失败再回头查要省事得多。判断类结论都有边界,如果你的客户端本身不支持本地工具,那不管中转站怎么配都做不到操作电脑,这时该换的是客户端而不是站点。
中转站管转发,客户端管动手;先分清谁碰你的电脑,再谈怎么配。下一步把你当前用的客户端和工具能力对照站内导航页过一遍,看哪些本地能力还没开、哪些站点在延迟上更稳,再决定从哪一层动手。→
常见问题
我把中转站地址填进 Codex 客户端了,为什么它还是不碰我的文件?
先分清能力来自哪一层。中转站只换接口地址和鉴权,本地文件读写靠客户端里开的工具能力。去检查客户端有没有启用本地执行相关的开关、工作目录有没有授权、是不是被系统权限拦住了。可以用一句普通对话验证中转站本身通不通,通了就说明问题在客户端侧,不在站点。
让 Codex 操作电脑,会不会把本地文件传到中转站?
会。它要决定下一步动作,就必须先把文件内容、目录结构或命令输出作为上下文发出去。所以正确的做法是圈一个专门的工作目录,别把整个盘开放;口令、密钥、客户资料这类文件不要放进去。具体的数据可见性判断可以对照站内隐私与安全相关页面。
配置过程中一直报错,怎么判断是站点的问题还是我这边的?
按从近到远的顺序退:先纯聊天验证账号和密钥,再让客户端打印实际请求地址与状态码,然后单独试一个最轻的本地动作。三步都过不了才怀疑站点。同时用测速页面量一次延迟基线,能把「慢」和「断」分开,这两种情况要采取的动作不一样。