[Feature Request] Use OpenAI Codex OAuth as a primary LLM provider

[FernandeZ-hjm]

Summary

Please support openai-codex (ChatGPT Plus/Pro OAuth) as a primary LLM provider in DeepSeek Harness, so users can select Codex models on the Models page instead of only invoking Codex as a subagent.

Tested against:

• npm: @deepseek-ai/dsh@0.1.0-rc.6
• repository: 47f943859bef60e4160492346772ded9b24f765a
• pi-ai: @earendil-works/pi-ai ^0.82.1

Current implementation evidence

Most provider-side building blocks already exist:

1. pi-ai ships the openai-codex provider, its model catalog, the openai-codex-responses protocol, browser/device-code OAuth, refresh logic, and CredentialStore integration.
2. DSH llm-pi-ai already materializes pi-ai catalog providers.
3. DSH intentionally withholds OAuth-only catalog routes from the configurable-provider directory because PiAiAdapter creates Models without a credential store and exposes only resolveApiKey.
4. The repository already ships dsh-subagent-codex, which delegates to the host codex app-server and reuses native Codex authentication, but this does not make Codex available as the parent session model.

The relevant code is in:

• packages/llm/llm-pi-ai/src/catalog.ts (catalogProviderTakesApiKey and the OAuth-only exclusion rationale)
• packages/llm/llm-pi-ai/src/adapter.ts (createModels() without CredentialStore)
• packages/llm/llm-pi-ai/src/index.ts (configurable-provider directory filtering)
• packages/subagent/subagent-codex/ (working native-Codex delegation path)

Expected behavior

• The Models page offers OpenAI Codex.
• A user can sign in with their own ChatGPT/Codex account through browser or device-code OAuth.
• The OAuth credential is persisted under DSH ownership with owner-only permissions and refreshed under a serialized store lock.
• Codex models can be selected as the default parent-session model.
• Sign-out removes only the DSH-owned credential.

Security boundary

DSH should use its own OAuth login and credential store. It should not read, copy, refresh, or overwrite ~/.codex/auth.json, because sharing a rotating refresh token between Codex CLI and DSH can invalidate one client and couples DSH to another products private file format.

Suggested implementation

1. Add a structured OAuth credential store owned by DSH (or a small adapter from a secure DSH credential service to pi-ai CredentialStore).
2. Construct each immutable pi-ai Models snapshot with that shared store.
3. Add host RPC operations for auth status, login, cancellation, and logout; bridge pi-ai AuthInteraction events to the Web UI.
4. Offer OAuth-only providers when the runtime has a persistent store and login surface.
5. Add keyless tests for store serialization, refresh persistence, cancellation, redaction, and provider-directory visibility; keep real OAuth as an opt-in e2e.

Because the contribution guide currently says external pull requests are not accepted, would the maintainers prefer this as a first-party capability, or as an ecosystem dsh-plugin? I can prepare a focused implementation after the intended ownership boundary is confirmed.

[FernandeZ-hjm]

Local protocol proof

I also ran a transient, in-memory proof against the installed pi-ai provider. No credential value was printed or written, and no repository file was changed.

1. Register openaiCodexProvider() in createModels({ credentials }).
2. Supply a valid OAuth credential through an in-memory CredentialStore.
3. Call completeSimple() with openai-codex / gpt-5.6-terra.

Result:

{"provider":"openai-codex","model":"gpt-5.6-terra","stopReason":"stop","text":"DSH_CODEX_OK"}

This confirms that the provider protocol and current model catalog work end to end. The missing product work is the DSH-owned OAuth credential lifecycle and login surface described above, not the model transport itself.

[Pygone]

hi, 我已经实现一个简单的实现

[Yan-Zero]

Looks at this Plugin: https://github.com/Yan-Zero/dsh-codex

[weijiafu14]

这个需求现在已经有可直接安装的通用实现：pi2dsh 0.3.1。它不是调用 Codex 子代理，而是让 OpenAI Codex OAuth token 进入 Harness 原生 LLM 路由，作为父会话主模型使用。

npm i -g pi2dsh@0.3.1
pi2dsh host --packages @narumitw/pi-accounts@0.49.7 --out ./dsh-pi-oauth
dsh plugin --profile web add pi2dsh@0.3.1 file:$PWD/dsh-pi-oauth

在 profile 的 cordis.patch.yml 中配置：

- id: credentials
  name: pi2dsh/credentials-oauth

- id: llm-pi-ai
  name: "@deepseek-ai/dsh-llm-pi-ai"
  config:
    providers:
      openai-codex:
        apiKeyEnv: PI2DSH_OAUTH_OPENAI_CODEX
        models:
          - id: gpt-5.6-luna

启动 Web 后执行：

/login openai-codex

授权流程使用 PKCE + localhost callback，无头环境可走 device code；凭证以 0600 权限独立落在 Pi 格式 auth.json，刷新采用按 provider 串行的双检锁轮换。pi2dsh/credentials-oauth 是标准 dsh-credentials provider，每次模型请求都会重新解析并刷新引用，token 不进入模型设置。

这条链路已经用真实 ChatGPT Pro 账号完整验证：浏览器授权 → token 落盘 → credentials provider → 官方 @deepseek-ai/dsh-llm-pi-ai route → DSH 原生 ctx.llm.stream() → gpt-5.6-luna 返回真实回复。也就是说已经覆盖你帖子里“作为 primary LLM provider”这一点。