Feature request: isolated custom-provider routing in Codex App without intercepting native OpenAI traffic

Feature request: isolated third-party provider support in the Codex App

Executive summary

The Codex App currently lacks an isolated extension boundary for optional third-party model providers.

Existing community workarounds redirect the app’s native OpenAI traffic through a local third-party proxy in order to add custom models to the model picker. As a result, a failure in the optional proxy can also disable native OpenAI/Codex models.

I am not requesting that OpenAI support or guarantee compatibility with DeepSeek, OpenCodex, or any other third-party provider.

I am requesting a provider-scoped extension mechanism that allows optional custom providers to coexist with the native OpenAI route without replacing or intercepting it.

Summary

Please consider providing a supported and isolated third-party provider extension mechanism for the Codex App.

The current community workaround for adding a third-party model to the Codex Desktop model picker requires redirecting the app’s OpenAI base URL to a local proxy and replacing or merging the model catalog.

This changes the reliability and trust boundary of the native OpenAI path, even when the user only intends to add one optional provider.

I documented a tested and reversible Windows workflow here:

https://github.com/Y1n1N1/opencodex-windows-safe-guide/tree/main

This is an independent community guide and is not affiliated with OpenAI, DeepSeek, or OpenCodex.

Tested environment

• Windows 11 x64
• Codex Desktop App 26.727.6591.0
• OpenCodex 2.10.0
• Node.js 24.18.1
• npm 11.16.0
• Local Responses proxy at 127.0.0.1:10100
• Validation date: 2026-08-02

What was verified

Using a local OpenCodex proxy, I was able to expose both of the following in the same Codex App model picker:

• Native OpenAI/Codex models from the existing Codex login
• deepseek/deepseek-v4-flash through a separately configured provider

Minimal requests to both providers were verified using proxy-side routing records, including:

• requested model;
• selected provider;
• effective or routed model;
• HTTP result.

The workflow also preserved the existing Codex login and conversation history.

Architectural problem

The workaround modifies the Codex configuration so that the native OpenAI endpoint is replaced with a loopback endpoint similar to:

openai_base_url = "http://127.0.0.1:10100/v1"
model_catalog_json = "...\\opencodex-catalog.json"

This creates several problems:

1. Native OpenAI requests also traverse the third-party local proxy.
2. If the proxy exits while Codex remains configured to use it, native model requests fail.
3. Adding one optional provider requires modifying shared Codex configuration.
4. Safe testing requires backups, diffs, isolated CODEX_HOME directories, route verification, and a rollback procedure.
5. A model appearing in the picker does not prove that requests are routed to the intended provider.
6. Proxy, provider, translation, and upstream failures may be surfaced through similar generic errors, making fault isolation difficult.
7. A Codex App update may change configuration or model-catalog behavior and silently break the integration.
8. Disabling or removing the optional provider may require manually restoring native routing configuration.

This is not being reported as an OpenAI defect in DeepSeek or OpenCodex compatibility. OpenAI has not promised support for this configuration.

The issue is that Codex currently lacks a documented extension boundary that allows an optional provider to coexist with the native OpenAI route without replacing or intercepting it.

Windows-specific observation

The following network issue is only an example of the coupling created by the current workaround. The feature request does not depend on this specific implementation detail.

In the tested environment, DeepSeek routing worked, while native OpenAI requests routed through the local proxy failed after approximately 20 seconds with errors such as:

• 502
• Provider unreachable
• Unable to connect
• upstream_server_error

The diagnosed cause was that the Bun/OpenCodex process did not inherit the Windows user proxy configuration required to reach chatgpt.com, even though the Windows system proxy was enabled.

Process-scoped HTTP_PROXY, HTTPS_PROXY, and loopback-aware NO_PROXY variables resolved that specific failure.

This was third-party proxy and network behavior, not evidence of an OpenAI service defect.

However, it demonstrates the architectural coupling: a network or runtime problem in the optional third-party bridge can also make native OpenAI models unavailable because both routes have been forced through the same proxy.

Requested design

Please consider a supported custom-provider interface with the following properties.

1. Isolated routing

Native OpenAI models should continue using the official Codex authentication and endpoint directly.

Only models belonging to a custom provider should be sent to that provider.

2. Provider-scoped credentials

Custom API credentials should be stored and managed separately and should not modify or replace the existing Codex login.

3. Additive, provider-scoped model catalogs

Third-party models should be additive and namespaced, without replacing the native OpenAI model catalog.

For example:

openai/gpt-...
custom-provider/model-name

4. Explicit route visibility

The UI or diagnostic tooling should make it possible to identify:

• requested model;
• selected provider;
• effective model;
• endpoint category;
• request result.

This would make it possible to verify actual routing rather than inferring it from the model picker.

5. Failure isolation

If a custom provider, local bridge, credential, or endpoint becomes unavailable, native OpenAI models should remain usable.

6. Safe enable, disable, and removal behavior

Users should be able to enable, disable, or remove a custom provider without manually editing or restoring shared configuration files.

7. Documented compatibility boundary

OpenAI could either:

• provide a supported custom-provider interface; or
• explicitly document that custom providers, model-catalog injection, and native-route interception are unsupported.

A clearly documented unsupported boundary would still be safer than relying on undocumented configuration behavior.

Why this matters

Users are already attempting to connect custom providers through community proxies.

Without an official isolation boundary, these integrations can unintentionally make native OpenAI functionality dependent on:

• third-party proxy availability;
• protocol translation correctness;
• local runtime behavior;
• operating-system proxy configuration;
• model-catalog injection;
• manual rollback procedures;
• undocumented Codex configuration behavior.

It also creates an unclear support boundary:

• the third-party provider may attribute failures to Codex;
• OpenAI may reasonably attribute them to the unsupported proxy;
• the proxy project may attribute them to an upstream API or Codex update.

The user is then left to determine which layer failed.

A narrow and explicit provider interface would reduce this risk without requiring OpenAI to guarantee the quality, safety, availability, or capabilities of third-party models.

Reproduction and supporting material

The linked repository contains:

• architecture and trust-boundary documentation;
• a tested Windows workflow;
• isolated CODEX_HOME testing;
• configuration backups and exact diffs;
• formal injection and validation procedures;
• dual-provider route verification;
• Windows proxy troubleshooting;
• rollback instructions;
• an issue-applicability matrix;
• sanitized response templates.

Repository:

https://github.com/Y1n1N1/opencodex-windows-safe-guide/tree/main

I can provide additional sanitized logs or configuration diffs if they would be useful.

I will not publish raw authentication tokens, cookies, account data, conversation contents, private file paths, or unredacted request headers.

{
  "error": {
    "message": "The requested model 'deepseek-v4-flash' does not exist.",
    "type": "invalid_request_error",
    "param": "model",
    "code": "model_not_found"
  }
}