Hosting opencodex as a proxy for multiple users with ChatGPT subscription passthrough and LiteLLM integration

[rafalkwol]

Hello,

This is a great project and I'm loving it so far. I have a question regarding using this as a proxy for multiple different users that would be centrally hosted. I would like to achieve a state where all the traffic from those users in Codex Desktop App (most are on Windows and some are on MacOS) will go through a centrally hosted opencodex and it will route all the traffic for their ChatGPT subscription using their own auth data to the standard endpoints they would have in the default Codex experience and route all the requests to other models to an instance of LiteLLM I'm hosting. So basically I just want to expand for the users the list of models from the default ones to additional ones without much hassle of running anything locally on their machines (except from maybe providing them the configuration files). Is this possible with the current version of opencodex or would it request some modifications? I don't want to take too much of anyones time so I only need the information if this is possible right now. If it is then I will spend some time figuring out how to achieve this myself if need be.

Best regards and thank you for your work.

[lidge-jun]

Hey @rafalkwol, thanks for the kind words and the clear question.

Short answer: the architecture already supports most of what you described, but opencodex is currently designed as a personal proxy (single-user, loopback). Multi-user hosting is on the roadmap — I'm planning to patch toward that direction and will keep this issue open to track it.

What already works today

• ChatGPT auth passthrough — the built-in ChatGPT provider uses authMode: "forward", which relays the caller's Authorization and chatgpt-account-id headers verbatim to upstream. The proxy never stores or manages ChatGPT credentials; each user's own OAuth token flows through untouched.
• LiteLLM routing — register your LiteLLM instance as an openai-chat adapter provider in the opencodex config. All non-ChatGPT model requests route there.
• Non-loopback binding — set "hostname": "0.0.0.0" and OPENCODEX_API_AUTH_TOKEN to expose the proxy on the network. The token protects both management and data-plane endpoints.
• Model catalog — the /v1/models endpoint serves the merged catalog (native gpt + routed LiteLLM models) over HTTP, so remote Codex clients see the expanded picker.

The gap: admission auth vs. ChatGPT auth

When bound to a non-loopback address, opencodex requires an admission token (x-opencodex-api-key header or Authorization: Bearer <token>) on every request. The problem is that Codex Desktop sends the user's ChatGPT OAuth token in the Authorization header — there's no built-in mechanism in codex-rs to send both the admission token and the ChatGPT token simultaneously without modifying the Codex client.

Recommended workaround (no codex-rs modification): put a reverse proxy (nginx, Caddy, etc.) in front of opencodex that:

1. Terminates TLS (you'll want this anyway — ChatGPT OAuth tokens should not travel in plaintext).
2. Injects the x-opencodex-api-key header from a shared secret or per-user auth layer.
3. Forwards the original Authorization header untouched so ChatGPT passthrough still works.

This keeps codex-rs completely unmodified on each user's machine — they only need openai_base_url pointing at your reverse proxy, plus a model_catalog_json pointing at a catalog file you distribute (or they can fetch it from the proxy's /v1/models).

Caveats to be aware of

• No per-user isolation — dashboard, usage logs, and request logs currently merge all traffic into a single view. There's no user/tenant concept yet.
• V2 sub-agents across providers — there's a known issue (V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content #92) where native-parent → routed-child sub-agents lose the task body in encrypted_content. If your users rely on sub-agents hitting LiteLLM models, this is a blocker until patched.
• Catalog distribution — each Codex client needs a local opencodex-catalog.json (or model_catalog_json in config.toml) for the model picker to show routed models. You can automate this by having your reverse proxy serve it, or by distributing the file alongside the config.

If you want to implement this now with AI assistance

If you'd like to fork and customize opencodex for your multi-user setup, here's a detailed prompt you can give to an AI agent to implement the changes. This approach keeps codex-rs completely unmodified — all changes are proxy-side:

AI implementation prompt

I need to modify opencodex to support centralized multi-user hosting behind a
reverse proxy. All changes must be proxy-side only — codex-rs on client machines
stays unmodified. Here is the scope:

1. ADMISSION AUTH SEPARATION
   - In src/server/auth-cors.ts, modify hasValidApiAuth() to check
     x-opencodex-api-key header FIRST and independently from Authorization.
     Currently it falls through to Authorization, which conflicts with ChatGPT
     OAuth tokens on the same header.
   - When x-opencodex-api-key is present and valid, admission is satisfied
     regardless of the Authorization header value.
   - When x-opencodex-api-key is absent but isApiAuthRequired() is true,
     check if the Authorization bearer token matches the admission secret.
     If not, reject with 401 — do NOT accidentally accept a ChatGPT OAuth
     token as an admission token.

2. FORWARDED AUTH PRESERVATION
   - In src/codex/auth-context.ts, headersForCodexAuthContext() must always
     preserve the original Authorization header from the incoming request for
     kind: "main" (passthrough) context, even when admission was satisfied
     via a separate x-opencodex-api-key header.
   - Verify that FORWARD_HEADERS in src/adapters/openai-responses.ts still
     includes "authorization" and that the ChatGPT OAuth token reaches
     upstream intact.

3. REQUEST LOGGING — OPTIONAL USER TAGGING
   - Add an optional x-opencodex-user-id header (or extract from the
     chatgpt-account-id header) to tag request logs with a user identifier.
   - This is informational only — no authorization decisions based on it.
   - Surface the user tag in the dashboard request log table if present.

4. DO NOT MODIFY
   - codex-rs client configuration beyond openai_base_url and
     model_catalog_json.
   - The ChatGPT OAuth flow or token storage.
   - The FORWARD_HEADERS list (it already covers what is needed).
   - Any provider adapter logic.

5. TESTING
   - Verify: a request with valid x-opencodex-api-key + ChatGPT OAuth in
     Authorization reaches the ChatGPT backend with the OAuth token intact.
   - Verify: a request with NO x-opencodex-api-key and a ChatGPT OAuth token
     in Authorization is rejected (401) when hostname is non-loopback.
   - Verify: loopback mode still works with no admission token at all.

The key files to modify are:
- src/server/auth-cors.ts (hasValidApiAuth, requireApiAuth)
- src/codex/auth-context.ts (headersForCodexAuthContext)
- src/server/request-log.ts (optional user tagging)
- gui/src/components/RequestLogTable (optional user column)

What I'd like from you

Could you describe your desired environment more concretely? Specifically:

• How many users roughly, and are they all on the same LAN or distributed (VPN/Tailscale/public)?
• Do you need per-user access control (e.g., some users can access certain LiteLLM models, others can't)?
• Are you planning to manage the ChatGPT subscriptions centrally, or does each user bring their own logged-in Codex Desktop?
• Any preference on the reverse proxy layer (nginx, Caddy, Cloudflare Tunnel, etc.)?

This will help me scope the multi-user patch properly. I'll keep this issue open and use it to track the work.

[rafalkwol]

Thank you for a very detailed answer.

From what I see it basically has nearly everything I need. Currently the issue with dashboard being single user is not a problem as I'm not planning to use it as I only need the proxy functionallity and proper routing of requests between models and ChatGPT subscrption with handling of image-gen (which opencodex seems to already handle). The blocked you mentioned is something I guess will probably be fixed sooner or later so also not a big issue.

The catalog distribution via file is the most "annoying" thing as I'm planning to change the models server by LiteLLM pretty frequently and would prefer users to not have to do anything at all to get the changes after initial config of the "openai_base_url" which I can set for them from the domain level probably.

The whole idea of this is like this:

• The company I work for uses ChatGPT Business for all our employees. This is a subscription that is quite fine for all the employees that don't use Codex very frequently and they are doing fine with their default limits. But more and more of our employees use Codex a lot and they often hit the default limits. We don't want to pay for the OpenAI credits as it's simply too expensive for the size of our company and also we can't switch to Enterprise subscription as it will also be too expensive.
• To countermeasure this situation I provisioned some hardware that will allow us to host different local models that will have good enough quality to handle most of the typical Codex work for our power-users. I was planning to proxy all those models on different machines (we have 3 separate machines with GPUs of different quality) under one LiteLLM instance so I can manage this centally with proper user access permissions and also having some models that will not be available via Codex, but will be used for internal automations in n8n and some other tools.
• The issue I encountered is the way Codex handles external models providers. As you for sure know it has this akward way of enabling other models via the *.toml file which also causes by default the ChatGPT subscription models to disappear. I really want to provide a solution for our employees that will be seamless for them so they will just see additional models in their model picker on top of the models they already have from their subscription. When their subscription limit runs out they can just simply switch to local models and continue their work with a bit worse quality.

Now to answer your questions:

• The number of users will be somewhere between 90 to 150, but it's probably never will be exactly at the same moment and requests will just come in smaller batches, because it's not like everyone use Codex 24/7. All of the employees work over LAN if they are in the office and those that are not will be connected via VPN. I'm also considering in the future I may make the endpoint for access public and just have some kind of API key authorization layer in the middle, but it's not a priority right now. We have all the infrastruction on-premise in our company and we don't use any cloud providers.
• I would like to have the ability to give users access to specific models. I was planning to do this somehow via LiteLLM and I just need something that I can use to differentiate users and it should be a simple thing after I get something like this. I was planning to extract some kind of identifier of the user from their ChatGPT subscription token if it will be possible, but didn't analyze it yet if it's possible.
• I don't want to manage ChatGPT subscriptions centally by default. I want them to normally login to Codex on their own and just use their auth credentials sent to the proxy to authenticate them in ChatGPT subscription and maybe as I mentioned in previous point also extract some identifying information from this token. In the future it may be nice to be able to buy some additional subscriptions for ChatGPT and give access to other users to a shared additional pool, but it's not something I was originally planning, but after I saw this functionallity in opencodex I though it's a nice idea and the only issue I see they threads being stuck to some other random subscription then the one assigned to the employee.
• I like to work with nginx as a proxy as I know it best from the ones you mentioned.

Again, thanks for your work. This is already a really good solution and if push comes to shove I will try to tinker with it myself if I will miss something that won't be planned by the roadmap.

Best regards.

[Wibias]

@rafalkwol

I tested the suggested nginx workaround locally on Windows and can confirm that it works in practice.

Test environment:

• Windows 10.0.26200
• Codex Desktop 0.144.0-alpha.4 / 26.707.51957
• OpenCodex v2.7.8
• nginx 1.27-alpine running in Docker Desktop
• OpenCodex on port 10100
• nginx exposed locally on 127.0.0.1:18080

Configuration:

• nginx injected x-opencodex-api-key
• the original Authorization header was preserved
• chatgpt-account-id was forwarded unchanged
• Codex Desktop used the nginx endpoint instead of connecting to OpenCodex directly

Successfully tested:

• merged model catalog via GET /v1/models
• routed Anthropic requests via POST /v1/responses
• native OpenAI requests with gpt-5.4
• switching from an Anthropic model to a native OpenAI model inside an existing thread
• image generation via POST /v1/images/generations using gpt-image-2

All tested requests returned HTTP 200.

Example nginx log entries:

GET /v1/models HTTP/1.1" 200
POST /v1/responses HTTP/1.1" 200
POST /v1/images/generations HTTP/1.1" 200

This confirms that the proposed request flow works in a real single-user Windows setup:

Codex Desktop -> nginx -> OpenCodex -> provider

Limitations of this test:

• single user only
• no simultaneous multi-account testing
• no per-user isolation or permission testing
• no concurrency or load testing
• no LAN, VPN, or public deployment testing
• no dynamic remote model-catalog refresh testing

So this does not validate the full multi-user production scenario yet, but it does confirm that the nginx admission-auth workaround works with native OpenAI models, routed providers, model switching, and image generation.

[Wibias]

I also tested how provider and model catalog changes propagate from Ollama through OpenCodex into Codex Desktop.

Test setup

• Windows 10.0.26200
• Codex Desktop 0.144.0-alpha.4 / 26.707.51957
• OpenCodex v2.7.9
• Ollama running locally on http://127.0.0.1:11434
• nginx in front of OpenCodex as described in my previous comment

Adding a new Ollama model

Ollama immediately exposed the newly added model through its OpenAI-compatible endpoint:

Invoke-RestMethod http://127.0.0.1:11434/v1/models

However, the model did not appear immediately in the OpenCodex catalog:

(Invoke-RestMethod http://127.0.0.1:18080/v1/models).data |
    Where-Object id -Like "ollama/*" |
    Select-Object id

I then monitored the OpenCodex catalog without restarting OpenCodex and without running another sync.

The new model appeared automatically after:

264.8 seconds

This suggests that OpenCodex refreshes provider model catalogs in the background, likely on an interval of approximately five minutes.

ocx sync behaviour

During the test, running:

ocx sync

did not cause the newly added Ollama model to appear immediately in /v1/models.

The model appeared later through the background refresh.

So ocx sync appears to write the model catalog currently known to OpenCodex into the local Codex catalog, but it does not necessarily force an immediate synchronous provider rediscovery first.

Codex Desktop model picker

Once the model appeared in OpenCodex /v1/models, the running Codex Desktop application still did not update its model picker.

The new model appeared only after fully restarting Codex Desktop.

The same behaviour was observed when removing a model:

• the removed model disappeared from OpenCodex after the provider refresh
• it remained visible in the running Codex Desktop model picker
• it disappeared after restarting Codex Desktop

The same restart requirement also applied when adding the Ollama provider itself.

Observed refresh flow

Provider or model change in Ollama
-> OpenCodex background catalog refresh
   observed delay: 264.8 seconds
-> Codex Desktop restart
-> updated model picker

Practical impact

This means centralized model changes are possible without manually editing or redistributing a new catalog file for every individual model change.

However, the experience is not fully dynamic from the end user's perspective:

• provider changes can take several minutes to appear in OpenCodex
• Codex Desktop does not refresh the model picker while running
• users must restart Codex Desktop to see added or removed models

For the multi-user scenario discussed in this issue, this is still workable, but users would need to be told to restart Codex Desktop after model catalog changes.

[rafalkwol]

@Wibias Thanks for the tests you made. From their conclusion it seems to me the only things left to validate for MVP scenario is concurrent multi-user access while hosting opencodex on remote server and also the possibility of extracting some user identifying information from their ChatGPT auth token.

[Wibias]

Agreed. I can validate concurrent request handling in a controlled local setup using multiple Codex Desktop/CLI clients against the same nginx and OpenCodex endpoint.

That would cover concurrent native, routed and image-generation requests, but it would still use a single ChatGPT identity. A true multi-user validation would require at least two separate ChatGPT accounts and isolated Codex client profiles, so the original company environment may be better suited for that final test.

For user identification, I think it would be safer to investigate the forwarded chatgpt-account-id header before attempting to parse the OAuth bearer token itself.

The questions I would validate are:

• whether chatgpt-account-id is present on forwarded ChatGPT requests
• whether it is stable across sessions for one user
• whether it differs between users
• whether OpenCodex can derive and forward a non-reversible internal identifier, such as a salted hash
• whether that identifier can be passed to LiteLLM for per-user access policies

I would avoid logging or storing the raw Authorization header. If chatgpt-account-id is not sufficiently trustworthy or stable, the cleaner production design would probably be to establish user identity at nginx through company SSO or VPN authentication and pass a trusted internal user header to OpenCodex/LiteLLM.

[rafalkwol]

Thanks for the summary. I was thinking about the chatgpt-account-id also, but i'm not sure it will be easy to map to user identities without some manual work. I'm also thinking about injecting the salted hash into the link of openai_base_url which I would populate for each user from domain so I would be able to embedd their identity into the link which I would than extract on the proxy level. OAuth token parsing may indeed not be a good idea to go for as it's probably not realiable and may not have any easly identifiable information.

I will try out those ideas when I get to it in our internal environment. It's still some time to go as right now we are working on hosting the local model on the provisioned hardware, but after we get the LiteLLM gateway fully running we will go for opencodex next. Just like to plan ahead of time. :) Thanks the time spent on this.