
Codex 0.164.0: Enterprise MCP Sign-In
Codex 0.164.0 adds enterprise MCP authentication using eligible Codex account grants or dedicated sign-in, including support for OAuth clients that require secrets. Learn what to verify before configuring a gateway, plus caveats around remote MCP settings, token refresh, credential masking, and several useful CLI and session fixes.
Chapter 1
Enterprise MCP authentication in 0.164.0
Ethan Park
Morning, everyone. Before anything else, thanks to Jellypod for helping make this daily show a reality. Today's topic is Codex 0.164.0, which shipped on October 23, 2026. If you've ever tried to point an agent at an MCP server sitting behind an enterprise gateway, this release changes how that sign in works.
Ethan Park
Here's the change, straight from the release notes. Codex can now authenticate enterprise MCP connections in two ways. The first is to use eligible Codex account grants, so the credentials you already have with Codex can be reused. The second is a dedicated sign in for that MCP server. The notes also say this covers OAuth clients that require secrets. Those are confidential clients, the kind many enterprise identity setups issue. The pull requests listed for the headline item are 55334, 55859, and 56001.
Maya
The practical impact is easiest to see by looking at the supporting commits in the full changelog, because they show what the team had to handle. There's one titled Reuse Codex account grants for enterprise MCP authentication, number 55698. There's one that rechecks account login ownership for enterprise MCP, 55680. Another preserves enterprise MCP authorization across runtime refreshes, 55696. And another refines the enterprise MCP auth errors, 55691. Put together, that reads as: reuse the grant you have, verify it still belongs to the account that's signed in, keep it alive when the runtime refreshes, and give you a clearer error when it fails. That's my reading of the commit titles, not something the notes spell out in those words.
Ethan Park
So how do you use it? I'll be upfront about a gap. The notes tell us what the feature does, but they don't print config syntax. The summary we worked from describes defining your enterprise server under an mcp_servers section in your Codex configuration, where you can supply a client secret or choose account grant inheritance. It also describes a slash command, /mcp login followed by the server name, to start the dedicated sign in when a grant needs first time consent or has to be renewed. I can't confirm those exact key names or the command from the official release notes. So the workflow is this. Update to 0.164.0. For npm users that's npm install, dash g, at openai slash codex at 0.164.0. Then check the current docs for your version for the exact fields before you commit anything to a shared config.
Maya
And since a client secret is involved, think about where that secret lives before you write it down. Don't paste it into a config file that goes into a repository. The notes don't tell us how Codex stores it, so treat that as a question for the docs, or for whoever administers your identity provider. If your organization issues confidential clients, they're the ones who can tell you whether your MCP gateway expects the account grant path or its own sign in.
Ethan Park
A few caveats worth knowing. First, remote environments. Change 53990 keeps host MCP and plugin configuration local when you're working with remote environments. So if you run against a remote exec server, don't assume your MCP definitions travel with the task. Second, change 54079: rejected MCP OAuth refresh tokens are now retired. If the server turns down a refresh token, Codex drops it. In practice, that means you should expect to sign in again rather than watch silent retries loop in the background. Third, 55701 turns on MCP OAuth refresh coordination by default, which is aimed at the case where several sessions try to refresh the same credentials. The notes don't say more than that, so test it with your own multi session setup.
Maya
There's also a security adjacent feature in the same release that matters if you handle these secrets. Codex now masks credentials during supported remote Bash commands and Zsh snapshot sessions, including credentials from custom providers. The key word is supported. If you're running remote exec servers and passing secrets around, confirm masking is actually active in your setup. One related change, 55719, lets unified exec fall back when credential masking is unavailable. So there's a path where a command still runs without masking, and I'd read that as a reason to check rather than assume.
Ethan Park
One more item in the headline list, for anyone on AWS. The Amazon Bedrock setup wizard is now enabled by default. When Codex detects AWS credentials, the API key entry is grouped alongside the other AWS sign in methods. Before this you'd need to turn the wizard on yourself. Now it's just there when credentials are detected, so check how it behaves on a machine that has several AWS profiles.
Chapter 2
Smaller fixes worth a mention
Maya
Now the smaller fixes, because several of them remove real annoyances. Resuming a session now finds compressed histories and restores saved thread settings. Before, a resumed thread could end up with the global defaults replacing what you'd chosen, so your model or permissions might quietly change. If you've resumed a long running thread and felt the behavior shift, that's the sort of bug this targets. The changes are 54008 and 55923.
Ethan Park
Next, configuration overrides. The CLI now preserves them when the config flag, short or long form, shows up at more than one subcommand level. If you wrap Codex in scripts and pass an override at the top and another further down, the earlier one used to be at risk of getting lost. That's change 56022. Also, queued prompts now wait for pending permission selections to resolve before continuing. If you stack prompts while an approval is open, they won't run ahead of your decision. That's 55682.
Maya
Two more. On Windows, HTTPS and WebSocket connections now handle proxy authentication challenges using the signed in user's Negotiate or NTLM credentials. If you're on a corporate network with an authenticating proxy, that's meaningful. And there's sandbox hardening: checks for case variant metadata paths on macOS, and for replaceable symlinks used to locate executables. Those are 54273 and 55384. Last, housekeeping. Codex now prunes unused installations, cleans abandoned marketplace checkouts, and bounds daemon logs, so it should stop quietly eating disk.
Ethan Park
So the action list is short. Update to 0.164.0. If you use enterprise MCP, find out which sign in path your gateway expects and read the docs for the exact configuration. Treat any client secret like a secret. And if you run remote environments, verify that credential masking is on. That's it for today.