You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are trying to build an internal team setup where developers can use Codex for AI-assisted coding through a shared remote Headroom Proxy, which then connects to Azure AI Foundry / Azure OpenAI.
Target architecture:
Developers' local PCs running Codex
-> Remote Headroom Proxy container
-> Azure AI Foundry / Azure OpenAI API
Our goals are:
Developers should run Codex locally on their own PCs.
Codex should connect to a remote Headroom Proxy using a custom Codex profile, for example:
codex --profile headroom
The remote Headroom Proxy should optimize/compress context before forwarding requests.
The upstream model provider should be Azure AI Foundry / Azure OpenAI.
Azure endpoint and API key information should be managed only on the remote server side.
Developers should not have direct access to Azure API keys.
The setup should support Codex coding workflows, including Responses API streaming.
We want to use this internally within our development team for vibe coding / AI-assisted development.
Current architecture we are testing:
Codex on developer PC
-> Remote Headroom Proxy container
-> Azure adapter or proxy layer if needed
-> Azure AI Foundry / Azure OpenAI API
Questions:
Is this architecture supported or recommended?
What is the correct configuration for Codex custom provider profiles when using a remote Headroom Proxy?
Can Headroom Proxy directly forward requests to Azure AI Foundry / Azure OpenAI?
Does Headroom support Azure OpenAI API key authentication directly, including Azure's required api-key header?
If Azure requires an adapter layer, what is the recommended architecture?
Are there known issues with Codex custom providers and Responses API streaming?
Why would simple curl requests to Headroom or Azure succeed, while Codex fails with errors like:
Model metadata not found
Stream disconnected before completion
stream closed before response.completed
How should model metadata be configured when Codex uses Azure deployment names?
Is there a known working reference configuration for:
If this architecture is not currently reliable, what is the recommended alternative for a team-wide Codex + Azure AI Foundry setup where Azure API keys are centrally managed and not exposed to developers?
We would appreciate a working example configuration for:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
We are trying to build an internal team setup where developers can use Codex for AI-assisted coding through a shared remote Headroom Proxy, which then connects to Azure AI Foundry / Azure OpenAI.
Target architecture:
Developers' local PCs running Codex
-> Remote Headroom Proxy container
-> Azure AI Foundry / Azure OpenAI API
Our goals are:
Developers should run Codex locally on their own PCs.
Codex should connect to a remote Headroom Proxy using a custom Codex profile, for example:
codex --profile headroom
The remote Headroom Proxy should optimize/compress context before forwarding requests.
The upstream model provider should be Azure AI Foundry / Azure OpenAI.
Azure endpoint and API key information should be managed only on the remote server side.
Developers should not have direct access to Azure API keys.
The setup should support Codex coding workflows, including Responses API streaming.
We want to use this internally within our development team for vibe coding / AI-assisted development.
Current architecture we are testing:
Codex on developer PC
-> Remote Headroom Proxy container
-> Azure adapter or proxy layer if needed
-> Azure AI Foundry / Azure OpenAI API
Questions:
Is this architecture supported or recommended?
What is the correct configuration for Codex custom provider profiles when using a remote Headroom Proxy?
Can Headroom Proxy directly forward requests to Azure AI Foundry / Azure OpenAI?
Does Headroom support Azure OpenAI API key authentication directly, including Azure's required
api-keyheader?If Azure requires an adapter layer, what is the recommended architecture?
Are there known issues with Codex custom providers and Responses API streaming?
Why would simple curl requests to Headroom or Azure succeed, while Codex fails with errors like:
How should model metadata be configured when Codex uses Azure deployment names?
Is there a known working reference configuration for:
Codex
-> Headroom Proxy
-> Azure AI Foundry / Azure OpenAI
If this architecture is not currently reliable, what is the recommended alternative for a team-wide Codex + Azure AI Foundry setup where Azure API keys are centrally managed and not exposed to developers?
We would appreciate a working example configuration for:
All reactions