Codex App (WSL mode): Missing environment variable `AZURE_OPENAI_API_KEY` although variable exists in Windows and WSL

Are you sure the environment variable is exported? Can you see its value VS Code's built-in terminal?

yes, in VSCode connected to the same repo in WSL and executing "printenv AZURE_OPENAI_API_KEY" -> I see the key.

<img width="1019" height="400" alt="Image" src="https://github.com/user-attachments/assets/d9a9e4e9-ead0-465e-971a-79bbbe0dd97e" />

Fixed ?
same for the ZenMux provider

Also seeing this issue. A related issue is that the environment dropdown (cog in the top right) is not visible for new chats and that a newly created environment has to be manually selected using the environment dropdown, which only appears once you start the session, then still doesn't seem to work once turned on.

<img width="1475" height="701" alt="Image" src="https://github.com/user-attachments/assets/d255f2e7-d158-4d88-a375-250064ac6d41" />

<img width="1472" height="801" alt="Image" src="https://github.com/user-attachments/assets/0664a265-fd44-4c61-9c73-06a052ad1eb4" />

+1 on this. Did you find a way around?

+1

+1

I've kind of found the solution. The issue was my AZURE_OPENAI_API_KEY wasn't setting permanently in WSL.

So for me the solution was to set the key permanently and this is how I managed to do it:

1. In Windows set AZURE_OPENAI_API_KEY and value in Edit environment variables for your account --> User variables interface.
2. Then we need to share this key with the WSL, so in the same window look for a variable named WSLENV or create one and set the value to AZURE_OPENAI_API_KEY/u (/u is important)
3. Restart WSL (using wsl --shutdown)
4. Restart the Codex app

If this doesn't work, try this:

In WSL terminal:

1. nano ~/.bashrc
2. Paste this at the very bottom: export AZURE_OPENAI_API_KEY="you-key"
3. Save and Exit
4. source ~/.bashrc
5. Restart the Codex app

Let me know if it helps.

Same problem here with codex app in wsl mode, although it works in cli and in the VSC codex extension, in wsl.

That's the config I am testing with:

model_provider = "openrouter"
model_reasoning_effort = "low"
model="xiaomi/mimo-v2.5-pro"

[model_providers.openrouter]
name = "openrouter"
base_url="https://openrouter.ai/api/v1"
env_key="OPENROUTER_API_KEY"

Error: Missing environment variable: OPENROUTER_API_KEY.

But when I open a terminal in the codex app and run echo $OPENROUTER_API_KEY it outputs the value.

Same issue here — OpenRouter provider on native Linux (Oracle Linux 9, aarch64), Codex CLI v0.142.5, deepseek/deepseek-v4-flash.

Config:

model = "deepseek/deepseek-v4-flash"
model_provider = "openrouter"
model_reasoning_effort = "high"

[model_providers.openrouter]
name = "openrouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

OPENROUTER_API_KEY was set in ~/.bashrc and confirmed via echo $OPENROUTER_API_KEY, but Codex still reported Missing environment variable: OPENROUTER_API_KEY.

Root cause: The persistent app-server daemon (codex doctor showed app-server running (persistent mode)) was holding stale environment from before the key was added to .bashrc. The daemon starts on first Codex launch and never picks up new env vars.

Fix that worked:

rm -f ~/.codex/app-server-daemon/app-server.pid
pkill -f codex
source ~/.bashrc
codex

This confirms the issue isn't WSL-specific — it affects native Linux when the app-server daemon predates the env var being set. The CLI itself works fine once the daemon is restarted with the correct environment.

I can reproduce this with the Codex VS Code extension when connecting through a VS Code Remote Tunnel to a Windows host and selecting WSL as the agent environment.

Environment:

• Codex extension: openai.chatgpt@26.814.41407
• Remote host: Windows
• WSL: Ubuntu 26.04, default user user
• Config: /home/user/.codex/config.toml
• Provider: Azure OpenAI using env_key = "AZURE_OPENAI_API_KEY"

1. The variable exists in the Windows VS Code host environment.
2. The host WSLENV contains AZURE_OPENAI_API_KEY/u.
3. A direct non-interactive launch receives it:

``powershell
wsl.exe --exec sh -c 'test -n "$AZURE_OPENAI_API_KEY" && echo SET || echo MISSING'
``

Result: SET.

1. The extension loads the correct WSL user and config file.
2. The live Codex app-server process does not contain the variable:

``text
HOME=present
USER=present
PATH=present
WSLENV=present
AZURE_OPENAI_API_KEY=missing
``

1. Inspecting WSLENV inside the live app-server process shows that it has been replaced with an extension-generated allowlist containing Windows system and proxy variables. The original AZURE_OPENAI_API_KEY/u entry is absent.

This suggests the WSL launcher constructs a new WSLENV value instead of merging its required entries with the existing host WSLENV. Consequently, wsl.exe itself propagates the variable correctly, but the Codex app-server is launched without it.

The same Azure configuration works when the tunnel and Codex extension run directly inside a WSL remote environment.

A likely fix would be for the Windows-to-WSL launcher to preserve and merge the existing WSLENV entries, or explicitly forward the environment variable referenced by the selected provider’s env_key.