#1231 Feature request: optional Codex runtime provider using ChatGPT-managed authentication

Summary

Add an optional codex LLM provider that runs TradingAgents through the locally installed, ChatGPT-authenticated Codex runtime.

The preferred integration is the official Python openai-codex SDK, which controls the local Codex App Server. codex exec may be retained as a simpler compatibility fallback, but should not be the primary runtime for a multi-turn, tool-calling agent graph.

This is not a request to use Codex authentication as an OpenAI API key. The provider must use Codex's managed local ChatGPT sign-in without extracting, forwarding, or translating its tokens.

Related: #1198 proposes keeping product-specific Codex adapters external. This issue asks whether a small, opt-in runtime provider belongs upstream, or whether maintainers prefer it to stay as an external integration.

Motivation

The current native OpenAI path requires OPENAI_API_KEY and langchain-openai. Users with an existing ChatGPT/Codex subscription may want an opt-in local integration without extracting tokens, reverse-engineering private endpoints, or running a custom API proxy.

OpenAI documents the following official surfaces:

The stable Python openai-codex SDK controls the local Codex App Server over JSON-RPC.
App Server supports managed ChatGPT authentication, which Codex persists and refreshes itself.
App Server can emit dynamic tool calls, although that interface is currently experimental.
codex exec supports scripted execution, JSONL output, and schema-constrained final output.

References:

Proposed design

Introduce llm_provider: codex with a dedicated LangChain-compatible adapter, for example CodexChatModel, and ship the SDK dependency as an optional extra such as tradingagents[codex].

1. Authentication

Require a working local codex login status session.
Prefer Codex-managed ChatGPT auth; do not use OPENAI_API_KEY.
Never read, copy, serialize, upload, or expose ~/.codex/auth.json.
Do not use the experimental externally-managed-token mode. The host should let Codex own token refresh.

2. Preferred transport: Python SDK / App Server

Use openai-codex to start isolated Codex threads and run agent turns from Python.
Give each TradingAgents agent/run a distinct Codex thread; do not accidentally share market context between independent runs.
Use a controlled working directory and a read-only sandbox by default.
Make the model, timeout, retry policy, concurrency cap, and working directory explicit configuration options.
Expose an actionable preflight failure when Codex is absent or no valid ChatGPT session is available.

3. Tool calls and structured output

TradingAgents currently relies on model-generated tool calls that are executed by local ToolNode instances. The Codex provider must preserve that loop rather than silently reducing the workflow to free-text output.

For full parity, adapt App Server dynamic tool-call events into AIMessage.tool_calls, execute the requested TradingAgents tool locally, and return its result to the same Codex turn.
Treat that dynamic-tool path as experimental and make its maturity visible in documentation and tests.
Implement structured output explicitly for the manager/trader/portfolio paths, or scope the first release to the paths it can support. Do not silently degrade the full graph.
A limited codex exec fallback may use --output-schema for final JSON, but it should not be the default transport.

4. Operational safeguards

Cap concurrent Codex turns; a full run creates many model calls and uses the account's subscription rate limits.
Use an ephemeral or isolated thread strategy as appropriate, and avoid cross-run state leakage.
Redact prompt/output logs by default and never log credentials.
Respect account rate-limit signals when the App Server transport is used.
Keep the provider opt-in; do not change existing defaults or the OpenAI API-key path.
Restrict this integration to trusted local/internal environments. Do not ship account auth into public CI, containers, or repositories.

Acceptance criteria

A user with a valid local ChatGPT Codex login can run an explicitly configured TradingAgents analysis without setting OPENAI_API_KEY.
The provider uses the Python SDK/App Server as the primary path; codex exec, if present, is documented as a fallback.
Existing OpenAI, Anthropic, Google, and compatible providers remain unchanged.
The provider does not access or copy Codex credential files.
Tests cover message conversion, thread isolation, auth preflight, timeout/error handling, and at least one mocked graph tool-call round trip.
Documentation clearly states the trusted-local-machine requirement, subscription/rate-limit caveats, and that this is not a direct OpenAI API integration.

Non-goals

Bypassing Codex/ChatGPT usage limits.
Calling undocumented OpenAI endpoints or translating Codex session tokens into bearer API credentials.
Shipping auth.json into CI, containers, or public repositories.
Changing the default model/provider or replacing the API-key integration.

Maintainer questions

Is an optional local Codex runtime provider in scope for this repository?
Should it live upstream, or should it be implemented as the external adapter anticipated by #1198?
Is the experimental App Server dynamic-tool interface acceptable for a parity-focused integration, or should the first contribution be limited to explicitly supported report-generation paths?