【记录】LLM｜配置登录 CodeBuddy 和 Codex 在 DeepSeek Harness

配置登录 CodeBuddy 和 Codex 在 DeepSeek Harness

最近在配置 DeepSeek Harness（DSH）时，我希望直接接入 CodeBuddy 和 OpenAI Codex。这样 DSH 仍然负责 Agent Loop、工具调用和上下文管理，而模型侧可以直接使用 CodeBuddy 和 ChatGPT/Codex 已有的登录与额度。

这里记录最终跑通的配置过程。我的环境是 Windows 本机 + 远程 Ubuntu 服务器，DSH 运行在服务器上，因此 Codex 登录还涉及 OAuth 回调和服务器网络代理两个问题。

安装和升级 DeepSeek Harness

首先安装 DeepSeek Harness：

npm install -g @deepseek-ai/dsh

如果已经安装，可以升级到最新版：

npm install -g @deepseek-ai/dsh@latest

检查当前版本：

dsh --version

DSH 的插件按照 Profile 管理。本文使用 Web Profile，因此后续插件安装命令统一使用：

dsh plugin --profile web ...

启动 Web 界面：

dsh web

升级 DSH 后，如果已经安装 CodeBuddy、Codex 等第三方插件，最好同时检查插件版本和兼容性，避免 DSH Plugin API 更新后继续运行旧版插件。

CodeBuddy

CodeBuddy 使用 @shatyuka/dsh-llm-codebuddy 插件。这个插件支持通过浏览器直接登录 CodeBuddy，不需要额外配置 API Key。

首先安装插件：

dsh plugin --profile web add @shatyuka/dsh-llm-codebuddy

安装完成后重启 DSH：

dsh web

然后进入 DSH Web 的 Settings，在 CodeBuddy 中登录即可。

也可以直接通过命令行登录：

dsh plugin --profile web exec dsh-codebuddy-login

查看登录状态：

dsh plugin --profile web exec dsh-codebuddy-login --status

退出登录：

dsh plugin --profile web exec dsh-codebuddy-login --logout

登录完成后，CodeBuddy 会作为新的 LLM Provider 注册到 DSH 中，可以直接选择 CodeBuddy 提供的模型。

Codex

Codex 使用 dsh-codex 插件。它支持通过 OpenAI 官方的 ChatGPT/Codex 登录流程认证，因此可以使用 ChatGPT 套餐中包含的 Codex 使用额度，而不是单独配置 OpenAI Platform API Key。

安装：

dsh plugin --profile web add dsh-codex

如果已经安装过，可以直接升级：

dsh plugin --profile web update dsh-codex

升级后可以运行插件自带的 Doctor 检查 DSH Plugin API 和相关依赖版本：

dsh plugin --profile web exec dsh-openai-codex doctor --json

如果输出中出现：

compatibility.status: incompatible

说明当前插件与 DSH 的相关依赖版本不完全匹配。此时可以先检查是否存在新版 dsh-codex，而不是直接忽略兼容性问题。

安装或升级完成后重新启动：

dsh web

然后进入：

Settings
→ OpenAI Codex
→ Sign in with ChatGPT

正常情况下会打开浏览器完成 OpenAI 登录。

远程服务器上的 OAuth 回调

我的 DSH 跑在远程 Ubuntu 服务器，而浏览器运行在本地 Windows，因此 OAuth 会多一个问题。

登录完成后，浏览器会被重定向到类似：

http://localhost:1455/auth/callback?...

这里浏览器中的 localhost 是 Windows 本机，而真正等待 OAuth callback 的 dsh-codex 运行在远程服务器。

因此需要使用 SSH LocalForward，把 Windows 的 1455 转发到服务器的 1455。

例如 SSH Config 可以配置为：

Host my-server
  HostName <SERVER_IP>
  User <USERNAME>
  Port <SSH_PORT>
  IdentityFile "<PATH_TO_PRIVATE_KEY>"

  LocalForward 1455 127.0.0.1:1455

其路径为：

Windows Browser
    ↓
localhost:1455
    ↓ SSH LocalForward
Ubuntu localhost:1455
    ↓
dsh-codex

修改 SSH Config 后需要重新建立 SSH 连接。

如果浏览器已经能够访问 localhost:1455/auth/callback，并且 DSH 随后报告的是 token exchange 阶段错误，那么通常意味着 callback 已经正常到达服务器，此时应该继续检查服务器访问 OpenAI 的网络路径，而不是继续修改 LocalForward。

让服务器使用本机代理

由于 DSH 运行在远程 Ubuntu 服务器，还需要让服务器能够借用 Windows 上已经配置好的本地代理客户端。

首先确认本地代理客户端提供的 HTTP/Mixed 代理端口。假设本机端口为：

127.0.0.1:7897

然后给 SSH 增加 RemoteForward。

为了避免 Windows 和 Ubuntu 两侧都使用 7897 导致排查时混淆，可以把服务器侧入口设置成 17897：

Host my-server
  HostName <SERVER_IP>
  User <USERNAME>
  Port <SSH_PORT>
  IdentityFile "<PATH_TO_PRIVATE_KEY>"

  LocalForward 1455 127.0.0.1:1455
  RemoteForward 17897 127.0.0.1:7897

此时代理路径为：

Ubuntu 127.0.0.1:17897
    ↓ SSH RemoteForward
Windows 127.0.0.1:7897
    ↓
本地代理客户端
    ↓
Internet

这里需要特别区分 LocalForward 和 RemoteForward：

OAuth Callback：

Windows :1455
    ↓ LocalForward
Ubuntu :1455


服务器访问外网：

Ubuntu :17897
    ↓ RemoteForward
Windows :7897
    ↓ 本地代理

两条隧道方向正好相反。

检查服务器代理是否真正可用

配置好以后不要急着测试 DSH，最好先使用 curl 单独验证网络链路。

首先在 Windows 查看本地代理的公网出口：

curl.exe -x http://127.0.0.1:7897 https://api.ipify.org

然后在 Ubuntu 上执行：

curl -x http://127.0.0.1:17897 https://api.ipify.org

两边如果得到相同的公网 IP，说明下面这条链路已经完整打通：

Ubuntu
  ↓
127.0.0.1:17897
  ↓ SSH RemoteForward
Windows 127.0.0.1:7897
  ↓
本地代理
  ↓
Internet

如果需要进一步检查 HTTPS，可以：

curl -v -x http://127.0.0.1:17897 https://api.ipify.org

正常情况下应该先看到：

HTTP/1.1 200 Connection established

随后完成 TLS 握手并得到 HTTP 响应。

这一步可以把 SSH 和代理问题与 DSH 本身的问题完全分开。如果这里已经正常，而 Codex 登录仍然失败，就应该检查 dsh-codex 的代理设置，而不是继续调整 SSH。

本地代理保持规则模式

如果本地代理直接使用全局模式，访问远程服务器本身的 SSH 流量也可能被送入代理节点，从而导致 SSH 无法连接。这样 RemoteForward 自然也无法建立。

因此可以保持代理客户端的规则模式，并把远程服务器 IP 设置为直连。

这里不需要为了让服务器使用代理而开启全局模式。服务器真正借用 Windows 本地代理依赖的是：

RemoteForward 17897 127.0.0.1:7897

Codex 的代理范围必须设置为 All dsh

这是整个配置过程中最容易忽略的一步。

一开始服务器代理已经可以正常工作：

curl -x http://127.0.0.1:17897 https://api.ipify.org

能够正确得到本地代理的公网出口，但是 Codex 登录仍然可能报告：

OpenAI Codex token exchange failed (403):
unsupported_country_region_territory

甚至：

dsh plugin --profile web exec dsh-openai-codex login --device-code

也可能遇到类似问题。

原因在于：

服务器能够通过代理访问 Internet

和：

dsh-codex 的 OAuth 请求实际使用这个代理

是两个不同的问题。

进入 DSH Web：

Settings
→ OpenAI Codex
→ Network proxy

配置：

Proxy URL:
http://127.0.0.1:17897

Scope:
All dsh

这里最关键的是：

Scope = All dsh

只配置服务器的 HTTP_PROXY，或者只让普通 Codex 模型请求使用代理，并不一定意味着首次 OAuth、device code、token exchange 等登录请求也会使用相同网络路径。

修改后重新启动：

dsh web

再执行：

Sign in with ChatGPT

此时整个登录过程就是：

浏览器登录
    ↓
OpenAI OAuth
    ↓
Windows localhost:1455
    ↓ SSH LocalForward
Ubuntu localhost:1455
    ↓
dsh-codex 收到 callback
    ↓
OAuth token exchange
    ↓ All dsh proxy
Ubuntu localhost:17897
    ↓ SSH RemoteForward
Windows localhost:7897
    ↓
本地代理
    ↓
OpenAI

配置正确后即可完成登录。

最终配置

最终 SSH Config 中同时存在两条端口转发：

Host my-server
  HostName <SERVER_IP>
  User <USERNAME>
  Port <SSH_PORT>
  IdentityFile "<PATH_TO_PRIVATE_KEY>"

  LocalForward 1455 127.0.0.1:1455
  RemoteForward 17897 127.0.0.1:7897

整体结构为：

                         Windows
                            │
          ┌─────────────────┴─────────────────┐
          │                                   │
    OAuth Callback                     本地代理 :7897
          │                                   ▲
 localhost:1455                              │
          │                                   │
          │ LocalForward          RemoteForward :17897
          │                                   │
          ▼                                   │
                    Ubuntu Server
                         │
                         │
                  DeepSeek Harness
                    ┌────┴────┐
                    │         │
                CodeBuddy    Codex

CodeBuddy 直接使用自己的浏览器登录流程；Codex 使用 ChatGPT/Codex OAuth。

对于远程服务器，LocalForward 1455 负责把本地浏览器收到的 OAuth callback 转交给服务器，RemoteForward 17897 → 7897 负责让服务器借用 Windows 的本地代理。本地代理使用规则模式，并保证远程服务器 IP 走 DIRECT；最后在 dsh-codex 中将 Network Proxy 设置为 All dsh，使登录阶段的网络请求也使用这条代理路径。

日后重新部署或维护时，主要记住下面几条命令即可：

# 安装 DSH
npm install -g @deepseek-ai/dsh

# 升级 DSH
npm install -g @deepseek-ai/dsh@latest

# 安装 CodeBuddy
dsh plugin --profile web add @shatyuka/dsh-llm-codebuddy

# 安装 Codex
dsh plugin --profile web add dsh-codex

# 升级 Codex
dsh plugin --profile web update dsh-codex

# 检查 Codex 插件兼容性
dsh plugin --profile web exec dsh-openai-codex doctor --json

# 启动 DSH Web
dsh web

这样配置后，DeepSeek Harness 可以同时使用 CodeBuddy 和 Codex，并且两者仍然使用各自原有的登录和额度体系。