Support signing in to subscription-only LLM providers (OpenAI Codex)

[netmindCjx]

English | 中文

llm-pi-ai exposes the installed pi-ai catalog, which includes providers whose only credential is an OAuth grant. openai-codex is the one people ask about: a ChatGPT Plus/Pro subscription has no API key, and a route is configured with apiKeyEnv, so today there is no way to use one.

Most of the machinery is already in the repo, which makes this smaller than it sounds:

• dsh-authorization defines the flow seam (registerFlow / begin / describe / list).
• packages/llm/llm-pi-ai/src/login.ts already registers one flow per installed provider that ships a login.
• Credential records already store an OAuth grant, and pi-ai refreshes it inside the store's modify().

Three things are missing:

1. dsh-authorization is mounted in no shipped composition. Registration is gated behind ctx.inject(['authorization'], …), so in every shipped profile those flows are never registered. The path is dormant rather than broken.
2. LlmConfigurableProvider has no field naming the credential a sign-in writes, so a configuration surface cannot tell a sign-in-only route from a key-configured one.
3. Nothing can reach a flow: no RPC on the settings controller, and no UI to carry a flow's prompts (the loopback page link, a device code) or report its outcome.

The benefit is that this is one seam, not one provider. A fact-driven predicate — the catalog entry offers OAuth and offers no API key — covers every OAuth-only provider at once, and it would give dsh-authorization its first production consumer; today it has none outside its own tests. Which of those providers to actually offer is a separate policy call, since some vendors' subscription flows authenticate as their own first-party client.

I have this working locally against a real Codex subscription (the grant lands as an llm-pi-ai/openai-codex record of kind grant), so the approach holds up end to end. Happy to share details if that is useful — I understand external PRs are not being accepted right now.

---

中文

English | 中文

llm-pi-ai 暴露的是已安装的 pi-ai catalog，其中有一些 provider 唯一的凭据形式是 OAuth grant。大家问得最多的是 openai-codex：ChatGPT Plus/Pro 订阅没有 API key，而一条路由是用 apiKeyEnv 配置的，所以目前无法使用订阅额度。

绝大部分机制其实已经在仓库里了，所以这件事比听起来小：

• dsh-authorization 定义了流程 seam（registerFlow / begin / describe / list）。
• packages/llm/llm-pi-ai/src/login.ts 已经为每个自带登录的已安装 provider 各注册了一条流程。
• 凭据记录已经能存储 OAuth grant，而 pi-ai 会在 store 的 modify() 内部完成刷新。

缺的是三件事：

1. dsh-authorization 没有被挂载进任何出厂 composition。 注册被 ctx.inject(['authorization'], …) 门控，因此在所有出厂 profile 里这些流程从未被注册。这条路是休眠，而不是坏了。
2. LlmConfigurableProvider 没有字段来命名一次登录所写入的凭据，于是配置界面无法区分"只能登录"的路由和"用 key 配置"的路由。
3. 没有任何东西能触达一条流程：settings controller 上没有对应的 RPC，也没有 UI 承载流程的提问（回环页面链接、设备码）或呈现最终结果。

它的收益在于这是一个 seam，而不是一个 provider。一个基于事实的判定——catalog 条目提供 OAuth 且不提供 API key——一次性覆盖所有仅支持 OAuth 的 provider，并且会让 dsh-authorization 拥有第一个生产消费者；目前它除了自己的测试之外没有任何消费者。至于其中哪些 provider 真的要开放，是另一个层面的政策判断，因为某些厂商的订阅流程是以其自家第一方客户端的身份进行认证的。

我已经在本地用真实的 Codex 订阅把这条路跑通了（grant 会落成一条 kind 为 grant 的 llm-pi-ai/openai-codex 记录），所以这个方案是端到端成立的。如果有帮助，我很乐意提供细节——我知道目前不接受外部 PR。

[irunningm]

Confirmed on the published 0.1.5 RC packages: the built-in Web Models editor exposes openai-codex, but does not provide a usable sign-in path. Adding the provider/models can leave a user with a selectable model that immediately fails.

Environment

• macOS 26.6.2, Node.js v26.8.1, Chrome, Web profile launched with npx @deepseek-ai/dsh web.
• @deepseek-ai/dsh: 0.1.5-rc.1
• @deepseek-ai/dsh-llm-pi-ai: 0.1.5-rc.2
• @deepseek-ai/dsh-client-ui-settings-models: 0.1.5-rc.2
• @deepseek-ai/dsh-web-frontend: 0.1.5-rc.2
• @deepseek-ai/dsh-authorization: 0.1.5-rc.2
• @earendil-works/pi-ai: 0.85.1

This was an existing Web profile with additional plugins, not an isolated clean-profile reproduction. No dedicated Codex OAuth UI plugin was installed. The versions above are the actual resolved local package versions.

Observed steps and failure

1. With no llm-pi-ai/openai-codex credential record, configure an openai-codex provider route and models.
2. Open Settings → Models → edit openai-codex.
3. The editor shows an API key field and custom settings, but no OAuth / “Sign in with ChatGPT” action. Reloading the page does not change this.
4. Select the configured model and send a message.

The session reports:

Provider is not configured: openai-codex
PI_AI_ERROR

The failed attempts recorded zero input/output tokens. The error does not direct the user to a supported authorization path.

End-to-end validation of the existing backend capability

A temporary local helper mounted the installed DSH LocalCredentialProvider, AuthorizationService, LlmRuntime, and llm-pi-ai plugin in a Cordis context. It used the existing authorization flow for llm-pi-ai/openai-codex, selected browser login, and let the user complete the OpenAI authorization page. No DSH package source was patched and no existing Codex CLI credentials were imported.

• The flow returned authorized and saved a record of kind grant through DSH's credential provider.
• The already-running DSH Web instance then successfully used the same configured openai-codex route.
• A subsequent user turn produced a model response, executed a tool, returned a final response, and ended with reason.kind: completed.

This supports the missing integration described above; it does not prove long-term token refresh behavior or availability of every model in the selector.

User-facing improvement

Please connect the built-in Web settings surface to the authorization flow, with sign-in status and actionable prompts. If OAuth-only providers are intentionally not supported in the shipped profile yet, the editor should explicitly explain that limitation instead of presenting only an API key field and allowing an apparently configured route to fail at first use.

No account identifiers, tokens, authorization URLs/codes, private conversation contents, or credential-file contents are included in this report.