文章摘要
本文介绍codex-plugin-dsh插件,该插件实现将本地Codex接入DeepSeek Harness(DSH),核心是为二者划分清晰职责边界,支持复用本地已登录的Codex账号,无需重复配置API密钥,明确了工具管控、上下文管理、安全隔离规则,同时给出了安装配置要求与流程。

LOCAL AGENT WORKBENCH 2026.08

把本地 Codex 接进 DeepSeek Harness:账号复用、工具权限和 Agent 工作台

账号复用、工具权限和 Agent 工作台

codex-plugin-dsh 架构拆解

PROVIDER TOOL LOOP

它不是给 DSH 多加一个模型名字,而是在两套运行时之间划清职责。

很多人第一次看到 codex-plugin-dsh,会把它理解成“在 DeepSeek Harness 里多接一个模型”。这个说法没错,但漏掉了真正重要的部分。

它解决的不是单次调用,而是运行时归属:Codex 负责推理、模型目录和原生图片生成;DeepSeek Harness(下文简称 DSH)继续掌管会话、工具、权限、插件与执行记录。两边通过本地 codex app-server 建立一条可持续的 Provider 通道。

安装插件并重启 DSH 后,模型选择器里会出现 Codex App Server(local)。选中它,Codex 就是当前会话的主模型,而不是被临时派出去完成一次任务的子 Agent。

01

核心接入逻辑

PRIMARY MODEL ROUTE

一句话概括:把本机 Codex CLI 暴露的 App Server 注册成 DSH 的标准 LlmAdapter 路由。

插件注册的路由名是 codex-app-server。DSH 原有的模型目录和浏览器模型选择器会自动发现它,不需要修改 DSH 源码,也不需要另做一套客户端插件。

subagent-codex:把某个任务委派给 Codex,完成一次子 Agent 调用。

codex-plugin-dsh:让 Codex 成为普通 DSH Session 的主模型,持续参与整段会话。

区别不在界面,而在控制权。前者是“调用一个能力”,后者是“替换当前会话的推理引擎”。

02

本地账号复用

LOCAL AUTHENTICATION

插件复用宿主机上由 codex login 管理的 Codex 账户。认证与产品设置仍由 Codex CLI 维护,插件不读取或保存 OpenAI API Key,也不要求把 Key 再填进 DSH。

这减少了重复凭证配置,也降低了密钥进入 Profile、环境文件或插件配置的机会。但“无需另配 API Key”不等于“无需认证”。

shell

npm install -g @openai/codex

codex login

codex --version

codex app-server --help

如果以后把 DSH 的 Subprocess 放到远程主机或隔离环境,Codex CLI 和登录状态也要位于那个执行环境。插件不会隔空借用另一台机器上的本地登录。

03

清晰的职责边界

OWNERSHIP BOUNDARY

这个插件最值得看的地方,是它没有让 Codex 和 DSH 同时争夺工具控制权。

DSH 持有:持久 Session、当前模型路由、系统提示、工具组装、外层 Agent Loop、权限策略、执行日志和子进程生命周期。

Codex App Server 负责:模型发现、账户认证、Thread 上下文、模型推理,以及被特意保留的原生图片生成。

中间的 Adapter 做翻译和桥接:把 DSH 消息转换成 App Server 请求,再把 Codex 发起的动态工具请求交还给 DSH。

DSH 默认模型只负责新 Session 的初始选择。一旦会话明确选中 Codex,就不会再把请求转给另一个默认上游兜底。

04

工具调用完全受 DSH 管控

TOOL LOOP BRIDGE

插件只接收 DSH 为本次请求组装好的 options.tools,不会自行扫描全局工具,也不会重建工具目录。

因此,DSH 的 preset、scope、allow/deny、code mode 与权限结果不会被绕开。Codex 能看到的,就是当前会话最终允许它看到的工具集合。

一次动态工具请求的暂停与续跑

插件把请求转换成普通 DSH tool-call,结束当前 Provider Step。

DSH Agent Loop 记录消息,Tool Runtime 完成权限检查、调度和执行。

工具结果写入 DSH 的持久日志。

下一次 Provider Step 把结果送回仍在运行的同一个 App Server Turn。

Codex 接着原来的推理继续生成。

插件本身不会偷偷执行第二遍工具。标准 DSH 工具事件仍是唯一的持久执行记录。工具返回的图片可以送回 Codex,后续上下文则通过 turn/steer 进入同一个 Turn。

05

对话上下文与回放状态

CONTEXT AND CHECKPOINT

把 Codex 作为主模型后,难点不只是“请求能发出去”,还要保证多轮上下文和工具暂停能接得回来。

插件为新的 DSH 模型回合启动一个受管 App Server 连接。连接会跨越同一 DSH Turn 的多个工具 Step 存活,直到回合完成、取消、超时、Session 关闭或插件卸载,随后由 DSH Subprocess Service 终止进程树。

成功回合会把 App Server 的 Thread ID、Turn ID 和工具目录签名写进 DSH Model Replay State。

工具签名未变化

从精确 Checkpoint 执行 thread/fork,继承动态工具目录。

工具签名发生变化

新建 Thread,再导入能够无损表示的 DSH 持久历史。

从其他 Provider 切换到 Codex 时,已完成文本、用户图片和工具历史也会通过 thread/inject_items 导入,模型切换不必从空白开始。

06

多模态输入与原生图片生成

MULTIMODAL PATH

用户上传的图片先经过 DSH Attachment Service 校验,再编码为内联 Data URL 发送给 App Server。App Server 不依赖 DSH 的本地附件路径,两边未来即使不在同一台机器上,也不要求共享文件系统。

Codex 原生 imagegen 是一个有意保留的例外。它由 App Server 直接执行,不进入 DSH 工具循环。生成结果会被解码、校验并保存为 DSH 图片附件,最后作为 Assistant 图片回写到原有对话。

能否使用生图能力,取决于当前 Codex 账户、所选模型与 App Server 能力。插件接通的是链路,不会替账户增加本来没有的权限。

07

安全隔离设计

CAPABILITY ISOLATION

同一套 Agent 同时拥有 Codex 原生工具和 DSH 工具,看上去能力更多,实际上会带来权限重叠、日志分叉和不可控执行。这个插件选择了更保守的做法。

只读 Sandbox + never Approval

Codex 自带 Shell、文件修改、Web 搜索、MCP、Apps、Plugins、view-image 和 multi-agent 能力会被关闭或拒绝。命令、文件变更与权限审批一旦仍由 App Server 发出,就按失败处理。

环境动作统一经过 DSH Tool Runtime,权限策略、Hook、工具日志和执行结果仍在一套系统里闭环。原生 imagegen 是唯一明确保留的例外。

插件没有把两套工具生态简单叠加,而是规定了谁负责思考、谁负责动手。

08

安装与配置流程

INSTALLATION WORKFLOW

Node.js:^22.19.0 或 ≥24

DeepSeek Harness:≥0.1.0-rc.5 且 <0.2.0

Codex CLI:≥0.147.0

账户:宿主机已经完成 codex login

安装到 DSH 的 web Profile:

shell

dsh plugin --profile web add github:wingoo/codex-plugin-dsh

从 DSH 源码仓库运行:

shell

pnpm dsh plugin --profile web add github:wingoo/codex-plugin-dsh

正式版本发布前,可以锁定已验证的 Commit:

shell

dsh plugin --profile web add github:wingoo/codex-plugin-dsh#<commit-sha>

更新已安装插件,不需要先卸载:

shell

dsh plugin --profile web update codex-plugin-dsh

安装或更新后,必须沿用原启动方式重启 DSH Web 服务,不要在同一端口另起第二个实例。服务恢复后刷新页面,再选择 Codex App Server(local)。

插件默认自动启用,也允许在 Profile 的 cordis.patch.yml 中覆盖可执行文件、模型缓存时间、目录读取超时、Turn 超时、退出宽限期和标准错误最大字节数。env 只适合显式的子进程环境覆盖,不应把凭证写入已提交的 Profile。

09

已知限制与验证边界

LIMITS AND EVIDENCE

尚未实现 DSH 交互问题桥接,App Server 的 requestUserInput 会直接失败。

其他 Provider 的 Reasoning Block 或 Assistant 图片不能完整导入 App Server。

工具目录变化导致 Thread 重建时,已有 Codex Reasoning 或 Assistant 图片无法无损迁移。

temperature、maxTokens、stop 等 App Server 无法兑现的参数会被明确拒绝。

项目文档称,作者已经在 macOS 上对模型发现、Web 模型选择、真实对话、DSH 工具调用、图片输入和图片生成回写做过真实 App Server 测试。Windows 批处理 Shim 已有单元测试,但真实 Windows 主机验证仍待完成。

证据边界:本文依据公开仓库、架构说明和周刊 Issue 整理,没有在当前环境安装插件或运行 Live Test。上述“已验证”指维护者公开说明的测试范围,不等同于本文的独立复测。

10

适用场景与不适用场景

FIT AND TRADE-OFFS

更适合这些场景

· 希望 Codex 成为整段会话主模型,而不是一次性子 Agent。

· 希望复用 DSH 的插件、权限、工具编排和执行日志。

· 不想在 DSH 中再保存一份 OpenAI API Key。

· 需要图片输入或 Codex 原生生图回写。

· 看重 Session 回放、Checkpoint 分叉和工具调用审计。

不太适合这些需求

· 要求 Codex 原生 Shell、MCP、Apps 与 DSH 工具同时全部开放。

· 要求所有 Provider 历史内容在切换时完全无损。

· 未经真实主机验证就直接投入 Windows 生产环境。

能力接入,控制权不外溢

Codex 提供推理与原生能力,DSH 提供工作台与治理。Provider Adapter 把两边接起来,又没有让控制边界变得含糊。

codex-plugin-dsh 的价值,不是把两个名字放进同一张界面,而是认真处理账号、会话、工具、权限和进程的归属。对本地 Agent 工具链来说,这比简单增加一个模型入口更值得参考。

以上内容不代表本平台立场,仅供读者参考