GUI Config does not work at all

[britus]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.506.31421 (2620)

What subscription do you have?

Free - does not metter with this issue - subscription makes not better :)

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

The Problem Shows the gap and openAI proves me right
me:
Show me the complete Codex MCP registration with token config.

ai:
Yes. Your current Codex registration in ~/.codex/config.toml is still without a token:

[mcp_servers.mcp_studio_server]
enabled = true
url = "https://127.0.0.1:8888/mcp"

Complete with a bearer token, it should look like this:

[mcp_servers.mcp_studio_server]
enabled = true
url = "https://127.0.0.1:8888/mcp"
bearer_token_env_var = "MCPSTUDIO_AUTH_TOKEN"
startup_timeout_sec = 20
tool_timeout_sec = 120

Then set the token before starting Codex:

export MCPSTUDIO_AUTH_TOKEN="<TOKEN_FROM_MCPSTUDIO>"
codex

Authorization: Bearer <TOKEN_FROM_MCPSTUDIO>

You get the token in MCP Studio under Server Config via the Copy Token button. Important: Restart Codex after setting the environment variable because running sessions do not reload the environment.

---

me:
Yes, here the obvious app design weaknesses of the OpenAI developers are evident. They come from the university with the "highest" degrees and qualifications, and yet, how am I supposed to set export MCPSTUDIO_AUTH_TOKEN="<TOKEN_FROM_MCPSTUDIO>" when I click on Application/Codex in macOS???

ai:
Yes, exactly, that's the desktop app gap: export ... is a shell reality, but a macOS app bundle launched via Finder/Dock does not see this shell environment. For a desktop app, this is quite impractical as the sole solution.

Practical options:

1. Set the token directly in ~/.codex/config.toml if Codex Desktop accepts the field:

[mcp_servers.mcp_studio_server]
enabled = true
url = "https://127.0.0.1:8888/mcp"
bearer_token = "<TOKEN_FROM_MCPSTUDIO>"
startup_timeout_sec = 20
tool_timeout_sec = 120

But:
In newer Codex versions, according to issues, bearer_token_env_var is the supported method. Whether bearer_token still works would need to be tested.

Launch Codex from the terminal, then export works:

export MCPSTUDIO_AUTH_TOKEN="<TOKEN_FROM_MCPSTUDIO>"
open -a Codex

Whether open -a passes the shell environment to the app depends on LaunchServices behavior and is not always reliable. A direct app binary launch would be more robust but ugly.

Permanently set via launchctl so that GUI apps see the variable:

launchctl setenv MCPSTUDIO_AUTH_TOKEN "<TOKEN_FROM_MCPSTUDIO>"
launchctl getenv MCPSTUDIO_AUTH_TOKEN

Delete later with:

launchctl unsetenv MCPSTUDIO_AUTH_TOKEN

For macOS GUI apps, option 3 is the realistic way if Codex does not offer its own UI for MCP headers/tokens. The clean solution would be: Codex Desktop should have a token field in the MCP server configuration and store it in the Keychain. That's exactly what Keychain is for.

---

me:
From my point of view, all of this is nonsense. A corresponding clean GUI configuration, which currently doesn't work at all in Codex, would be more sensible.

ai:
Yes, I agree with you. For a macOS desktop app, "set an environment variable" is not a real product solution but a developer workaround that falls apart in normal GUI usage.

A clean Codex GUI should at least be able to:

• Add/edit/delete MCP servers
• Configure URL, transport, timeout, enabled state
• Choose auth method: none, bearer token, custom headers
• Store token in macOS Keychain
• Test connection with visible error reason
• Display TLS/trust errors understandably
• Import/export config without secrets or with explicit secret handling
• Use the same config when starting from GUI as from CLI

For your case, the UI would look roughly like this:

And internally:

• ~/.codex/config.toml contains only non-secret metadata
• Token is stored in Keychain, e.g., Service Codex MCP, Account mcp_studio_server
• Codex Desktop loads server configuration on startup and retrieves secrets from Keychain
• CLI can use the same mechanism or optionally allow environment overrides

This would be the robust app solution. Everything else, especially launchctl setenv, is operational duct tape. It might work, but it's not the design that a desktop app should impose on its users.

What steps can reproduce the bug?

All the time. GUI does not work. Click on save do nothing

What is the expected behavior?

That this work in GUI App

Additional information

Rewrite/Refactor the part of MCP registration with Codex :)