[FEATURE]: support codex as a first-class provider (codex subscription rather than OpenAI api provider)

[PadishahIII]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

I would like OpenCode to support codex as a first-class provider for Codex-compatible Responses API endpoints. OpenCode already supports many providers through models.dev and generic SDK adapters. In this case, a models.dev entry alone is not enough because Codex-compatible gateways expect Codex CLI-style request construction, not only a model list:

• POST <baseURL>/responses
• top-level instructions and Responses API input
• store: false by default
• Codex compatibility headers such as x-client-request-id, x-codex-window-id, and installation metadata
• Codex tool formats, especially apply_patch as a Responses API custom grammar tool

The goal is to let users configure a Codex-compatible API base and use models like:

opencode -m codex/gpt-5.4

without relying on provider-specific proxy hacks or MITM rewriting.

Proposed scope:

• Add codex as a provider id available in auth/config flows.
• Route codex/* models through a native Responses API transport.
• Preserve configurable baseURL and API-key auth for user-specified Codex-compatible providers.
• Translate OpenCode messages and tool calls to the Codex-compatible Responses protocol.
• Add focused tests for provider loading, request construction, stream parsing, and tool-call handling.

I have a local proof of concept (here) that keeps the change focused on provider integration and includes tests, and I'm using my private build on codex subscription which works pretty good. If maintainers agree with this direction, I can open a PR linked to this issue.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: Add codex-compatible/claudecode-compatible provider #7728: [FEATURE]: Add codex-compatible/claudecode-compatible provider (closed) — nearly identical request for a Codex-compatible provider
• [FEATURE]: enable responses API in openai compatible provider #9628: [FEATURE]: enable responses API in openai compatible provider — overlaps with routing codex/* models through native Responses API transport
• [FEATURE]: Codex CLi feature/harness compatibility when using codex models #9454: [FEATURE]: Codex CLI feature/harness compatibility when using codex models — covers Codex tool suite (including apply_patch) and harness compatibility
• [FEATURE]: Add an explicit config option to force Codex-compatible request formatting #18203: [FEATURE]: Add an explicit config option to force Codex-compatible request formatting — directly addresses Codex-compatible request construction (instructions field, store: false, etc.)
• [FEATURE]: Claude/Codex via SDKs #22377: [FEATURE]: Claude/Codex via SDKs — similar request to use the Codex SDK/harness natively

Please review the above issues and consider whether this request can be addressed there or linked, to avoid fragmentation of the discussion.

[PadishahIII]

I implemented a first-class codex provider in my fork (https://github.com/PadishahIII/opencode) and I'm using my codex forwarding subscription in opencode pretty good. I've tested OmO and superpowers which works normally. I would like to turn my fork into a PR if maintainers are interested.

My fork: https://github.com/PadishahIII/opencode
About my private build: https://github.com/PadishahIII/opencode/blob/dev/docs/codex-private-build-guide.md