- Route all model traffic through the TrueFoundry AI Gateway for centralized access control, routing, and cost governance.
- Enforce Codex configuration consistently across every developer machine using MDM, including which gateway Codex talks to and how it authenticates.
- OIDC (
--codex-auth=oidc, preferred). The binary runs when Codex needs a token. The binary calls the OIDC flow and prints the access token. The managed file holds that command, not a token. Setup is in OIDC sign-in. - API key (
--codex-auth=api-key). The binary runs on the hourly schedule, signs in with device login, and writes that user’s gateway token intohttp_headers. The ChatGPT subscription setup requires this. What it writes is on Enforce with MDM.
tfy-local-ai-setup binary this guide deploys also enforces Claude Code and Claude Desktop (Cowork 3P) fleet-wide. Pass --codex to configure Codex only, or omit all tool flags to auto-detect and configure every client that is installed. Prebuilt binaries for every platform are on the releases page.Identity (prerequisite)
Before rolling out Codex, enforce SSO and workspace membership in your OpenAI admin console so access is tied to your IdP and employees can’t fall back to personal accounts. See OpenAI’s managed-configuration docs. Developers do not put a personal API key in the config. TrueFoundry sign-in uses the OIDC or API key method from the intro: OIDC runs when Codex needs a token; API key runs on the hourly schedule and writes the gateway token into the managed file.Route model traffic through TrueFoundry AI Gateway
Codex reads its model provider fromconfig.toml. Pointing it at the TrueFoundry AI Gateway means every request passes through a single control point before reaching any provider:
Enforce settings with MDM
Codex reads configuration in priority order, with the admin-controlled layer taking precedence over the developer’s own file. The mechanism differs by platform. macOS and Linux use/etc/codex/managed_config.toml:
managed_config.toml at all — Codex dropped it in v0.149.0 and now ignores that file with a startup warning. There is no registry equivalent. Two files under %ProgramData%\OpenAI\Codex replace it, and the MDM binary writes both:
C:\ProgramData\OpenAI\Codex, which the binary locks (owner Administrators, inherited permissions stripped, Users read-only). This matters: ProgramData lets any authenticated user create directories, and Codex loads whatever config it finds there rather than refusing a user-writable one. Do not relax that ACL.~/.codex/config.toml cannot move Codex off your gateway.
The tabs below show what the binary writes for each sign-in method. OIDC is preferred; use API key when you need the ChatGPT subscription setup or an older binary.
- OIDC
- API key
/etc/codex/managed_config.toml:C:\ProgramData\OpenAI\Codex\requirements.toml. command is the binary path alone:model key is written only when you set CODEX_DEFAULT_MODEL; otherwise model selection stays with the developer. On Windows that value is [models.new_thread], because requirements.toml has no top-level model key. Leave CODEX_DEFAULT_MODEL unset and that key is omitted too.Deployment scripts
The scripts below deploy and lock the admin-controlled config. On macOS, Linux, and Windows, pick OIDC or API key. Fill inOIDC_ISSUER and OIDC_CLIENT_ID from OIDC sign-in before you run an OIDC script. Schedule the script to run hourly so gateway URL and models stay current.
The scripts download the tfy-local-ai-setup binary from the truefoundry/tfy-local-ai-setup GitHub repo. The README there documents all available flags and advanced usage (config templates, manual runs).
How the script works
The script runs as root (Administrator on Windows) on a schedule (recommended: hourly). Steps 1, 2, and 4 are the same for both sign-in methods. Step 3 is the one that changes.
Each operating system has a full script for each sign-in method. Use the OIDC or API key tab below; the script is collapsed until you expand it.
-
Saves and loads config. On first run, the three required values (
GATEWAY_URL,CONTROL_PLANE_URL,TENANT_NAME) are read from the script’s Config section and written to a root-owned config file (macOS:/Library/Preferences/com.truefoundry.tfy-local-ai-setup.conf; Linux:/etc/tfy/tfy-local-ai-setup.conf; Windows:C:\ProgramData\TrueFoundry\tfy-local-ai-setup.conf). On subsequent runs the file is loaded automatically, so no changes to the script are needed. This is the same config file the Claude MDM script uses, so a machine running both shares one saved configuration. -
Installs or updates
tfy-local-ai-setup. Downloads the binary if it is not present or if the installed version does not matchRELEASE_TAG. On subsequent runs where the version already matches, this step is skipped entirely. -
Writes the sign-in config. The macOS, Linux, and Windows tabs below each spell this out for OIDC and for API key.
OIDC. The hourly run writes the command. It does not fetch a token. When Codex needs a token, Codex starts the binary, and the binary calls the OIDC flow. The first call opens a browser. Later calls refresh
~/.tf/oidc-refresh-token. API key. The hourly run signs in with device login and writes the gateway token intohttp_headers. The first run opens a browser. Later runs refresh~/.tf/refresh-token. -
Writes and locks the managed config. The binary builds the TOML with the AI Gateway URL and the sign-in config, then writes it and locks it so developers cannot modify it. On macOS and Linux that is
/etc/codex/managed_config.toml(chflags schg/chattr +i). On Windows it is bothrequirements.tomlandconfig.tomlunderC:\ProgramData\OpenAI\Codex, plus anicaclsACL on that directory so standard users cannot replace either file.
- macOS
- Linux
- Windows
- OIDC
- API key
/etc/codex/managed_config.toml. It does not fetch a token.- Codex starts
/usr/local/bin/tfy-local-ai-setupwhen it needs a token and reads the access token from stdout. - The binary calls the OIDC flow. The first call opens a browser.
- Later calls refresh
~/.tf/oidc-refresh-tokenin the logged-in user’s home directory and do not open a browser.
OIDC_ISSUER and OIDC_CLIENT_ID from OIDC sign-in. The top-level model key is written only when you set CODEX_DEFAULT_MODEL; otherwise model selection stays with the developer.--codex flag to auto-detect and configure every supported client that is installed (Claude Code, Claude Desktop, Codex), or add --claude-code and --claude-desktop alongside it to manage those explicitly in the same run.Verify the deployment
After the first run, work through the checks in order. The lock check is the same for OIDC and API key. The sign-in check is not.Check that the file is locked
- macOS
- Linux
- Windows
Ignoring deprecated managed config file at startup. That warning means a stale %USERPROFILE%\.codex\managed_config.toml is present from an older setup; Codex ignores it, but delete it to avoid confusion.Check the sign-in block
http_headers.- OIDC
- API key
[model_providers.truefoundry.auth]. command is the binary, and args starts with --_print-oidc-token. There is no Authorization line and no token in the file. On Windows the model, when you set CODEX_DEFAULT_MODEL, is under [models.new_thread].Send a test prompt
codex and send a prompt. The request should appear in the AI Gateway’s request logs, attributed to the logged-in developer.Preview the TOML without writing
Preview the TOML without writing
--dry-run prints the TOML and leaves the machine unchanged. Pick the sign-in method, then the operating system.- OIDC
- API key
- macOS and Linux
- Windows
OIDC sign-in
OIDC needstfy-local-ai-setup v1.4.1 or later. The scripts above pin v1.4.2.
Create the client
Set the issuer and client ID
- macOS and Linux
- Windows
What the binary writes
http_headers. There is no token in the file.- macOS and Linux
- Windows
command is /usr/local/bin/tfy-local-ai-setup.What happens when Codex needs a token
Behavior depends on the method set inCODEX_AUTH.
- OIDC
- API key
CODEX_AUTH is oidc:- Codex starts the binary and reads the access token from its stdout.
- The binary calls the OIDC flow. Codex does not.
- The first call opens a browser.
- Later calls refresh
~/.tf/oidc-refresh-tokenand do not open a browser. - That refresh token lasts for
refresh_token_ttlon the OIDC client. In the example on the MDM page that is 7 days. --codex-auth-modedoes not apply. OIDC ignores it.
Using Codex MDM with a ChatGPT Business or Enterprise subscription
This setup needsCODEX_AUTH="api-key". It does not work with OIDC.
If your organization buys Codex through a ChatGPT Business or Enterprise subscription rather than a usage-based OpenAI API key, the MDM setup requires one additional configuration step on TrueFoundry: you create an OpenAI model account that acts as a pass-through, and the OpenAI credentials are supplied at request time by each developer’s own ChatGPT account rather than stored on TrueFoundry.
This approach also gives you per-user usage attribution on both sides. TrueFoundry logs which user made each request, and OpenAI attributes usage to the individual ChatGPT seat. Codex sends its own ChatGPT OAuth token upstream, while a separate x-tfy-api-key header authenticates the developer to TrueFoundry, so every request carries their identity end to end.
Create an OpenAI model account on TrueFoundry
https://chatgpt.com/backend-api/codex. This is the endpoint Codex uses for ChatGPT subscription traffic, not the default OpenAI API endpoint.When prompted for authentication credentials, leave the API key field empty. Do not enter any API key or secret. The actual ChatGPT credentials are sent by Codex from the developer’s subscription session and forwarded by the AI Gateway at request time.Copy the model IDs
chatgpt-codex/gpt-5.2-codex). Copy these from the model account detail page, or create a virtual model that fronts them.Set the auth mode in the MDM script
api-key, switch the header style, and point Codex at the model you copied. Use the API key script, not the OIDC script.- macOS and Linux
- Windows
requires_openai_auth = true into the provider block and moves the TrueFoundry token from the Authorization header to x-tfy-api-key:requires_openai_auth = true tells Codex to attach the developer’s own ChatGPT OAuth token as the Authorization header. That frees x-tfy-api-key to carry the TrueFoundry credential, and the AI Gateway reads the two independently: x-tfy-api-key authenticates the developer to TrueFoundry, while the Authorization bearer is treated as the upstream provider credential and used to authenticate against OpenAI. With the api-key header style there is no ChatGPT token, so the TrueFoundry token travels in Authorization instead.
Using a virtual model with a ChatGPT subscription
The MDM setup works with virtual models as well. Point CODEX_DEFAULT_MODEL at a virtual model slug instead of a direct model ID and you get two immediate benefits:
- Fallbacks: if one target is unavailable, traffic automatically falls through to the next.
- Model changes without touching the MDM script: update the virtual model’s routing on TrueFoundry and the change takes effect across all managed machines with no script redeployment.
401 Unauthorized or 403 Forbidden can come from either side, and the fix differs:
- The developer’s ChatGPT session expired. They need to run
codexand sign in to their ChatGPT account again. - The TrueFoundry token expired. The next hourly MDM run refreshes it silently. To fix it now, run the commands on the API key tab in the browser-login FAQ below. This setup is API key only. Do not use the OIDC recovery.
401, 403 or 429 does not put the shared target into load-balancer cooldown, so one developer exhausting their ChatGPT quota cannot affect anyone else’s routing.
Observability with TrueFoundry
When Codex traffic flows through the TrueFoundry AI Gateway, you get built-in observability across both LLM and MCP requests, with no extra instrumentation. Request tracing: every request is traced with full attribution (user, model, token counts, latency, cost).

chatgpt-subscription flow, attribution lands on both sides: TrueFoundry records the developer’s identity from x-tfy-api-key, and OpenAI attributes the usage to that developer’s ChatGPT seat.
Data retention and compliance
Retention of prompts and outputs is governed by your agreement with OpenAI and differs between API and ChatGPT subscription plans. Review your enterprise agreement for the full scope, and see OpenAI’s managed-configuration docs for the admin controls available on your plan. On the TrueFoundry side, the AI Gateway is the single point where you control what is logged and where it goes: request tracing with per-user attribution, configurable prompt logging, and OTEL export into your own SIEM. Because all Codex traffic is routed through the gateway, your audit trail does not depend on any client-side setting a developer could change.Frequently asked questions
Why route Codex through TrueFoundry instead of straight to OpenAI?
Why route Codex through TrueFoundry instead of straight to OpenAI?
How does authentication work without distributing API keys?
How does authentication work without distributing API keys?
- OIDC. The binary runs when Codex needs a token. The binary calls the OIDC flow and prints the access token. The refresh token is
~/.tf/oidc-refresh-token. See OIDC sign-in. - API key. The binary runs on the hourly schedule. It signs in with device login and writes the gateway token into
http_headers. It refreshes that token from~/.tf/refresh-token. See API key.
How long do the refresh tokens last?
How long do the refresh tokens last?
- OIDC. The file is
~/.tf/oidc-refresh-token. It lasts forrefresh_token_ttlon the OIDC client. In the example on the MDM page that is 7 days. Each refresh replaces it, becauserefresh_token_max_usesis 1. - API key. The file is
~/.tf/refresh-token. It lasts 30 days from when it was last issued or rotated.tfy-local-ai-setupuses the TrueFoundry auth server’s refresh token and does not set its own expiry. Each successful run rotates it. If the script runs at least once within those 30 days, no browser sign-in is required. After 30 days without a refresh, the next run opens the device-login flow.
Does this MDM setup control which MCP servers Codex can use?
Does this MDM setup control which MCP servers Codex can use?
managed_config.toml, which covers the model provider and auth. Codex’s admin enforcement of which MCP servers a developer may enable lives in a separate requirements.toml (/etc/codex/requirements.toml on macOS and Linux) that tfy-local-ai-setup does not write, so deploy it alongside this script if you need that. See OpenAI’s managed-configuration docs for its format, and Codex web search for pointing Codex at a gateway-governed MCP server.Can I manage Codex on Windows?
Can I manage Codex on Windows?
tfy-local-ai-setup v1.3.5. Codex on Windows reads C:\ProgramData\OpenAI\Codex\requirements.toml (admin-enforced) and C:\ProgramData\OpenAI\Codex\config.toml (machine defaults); the binary writes and locks both, and locks the directory so standard users cannot replace them. It no longer reads ~/.codex/managed_config.toml — that was dropped in Codex v0.149.0.One caveat: Codex honors model_provider in requirements.toml only from v0.156.0. On older builds only config.toml applies, and that is the lowest-precedence layer, so a developer can override it from their own ~/.codex/config.toml. Check codex --version across the fleet before treating Windows Codex as enforced.I accidentally closed the browser login window. Do I have to wait for the next MDM sync?
I accidentally closed the browser login window. Do I have to wait for the next MDM sync?
- OIDC
- API key
tfy-local-ai-setup by hand.Related
- OpenAI Codex CLI: single-developer setup for both auth modes, plus MCP-based web search through the gateway.
- Enforce Claude settings with MDM: the same MDM binary for Claude Code and Claude Desktop, including Windows.
- Govern all AI traffic: which AI clients can be enforced via MDM and which need an on-device agent.
- TrueFoundry MCP Gateway: centralized MCP registry, auth, and audit trail.