Configuration for inherited environment variables

Bump!

I wanted to open a similar issue right now. This would be a great feature. I couldn't find any workaround this limitation

You can ask it to source the profile you use and it will.

Actually, I just realized. For my use case, you can simply use the --config to inject the env variable.

E.g.:

codex -c -foo.bar.env.SOME_ENV_VAR="value"

Have you tried to set this in ~/.codex/config.toml

[shell_environment_policy]
inherit = "all"

That solved it for me.

Have you tried to set this in ~/.codex/config.toml [shell_environment_policy] inherit = "all" That solved it for me.

I just tried this and it doesn't work. I can workaround this specific tool (because I built it) by adding support for config files (so it will read the value from ie ~/.config/sentire/config.json) but I'm concerned for all the other tools where I have no control on them.

I have tried both:

[shell_environment_policy]
inherit = "all"

As well as:

[shell_environment_policy]
inherit = "all"
experimental_use_profile = true

But neither worked - I use https://flox.dev/ for development environments and they rely on the environment being set right. This works totally fine in Claude Code, but I'm unable to get codex to behave at all.

This prevents me from using pretty much any CLI tools in Code: Github CLI, Jira CLI, all my custom CLI tools I've made specifically for AI's to use.

I'm seeing this issue only with specific variables. Does codex filter on "TOKEN" for security? None of the work-arounds from this thread are working for me.

🐳 developer@rocky-dev:/workspace$ env | grep GITLAB
GITLAB_HOST=10.89.1.2
GITLAB_TOKEN=test
🐳 developer@rocky-dev:/workspace$ codex 'run env | grep GITLAB'
...
> Listing environment variables and filtering for GITLAB-related entries.

• Ran env | grep GITLAB

> - GITLAB_HOST=10.89.1.2

I was able to work around this by creating a function that loads the key from a file and sets it when running the underlying glab command.

glab() { local token; token=$(tr -d ' \n\r' < ~/.gitlab_token); GITLAB_TOKEN="$token" ~/go/bin/glab "$@"; }

This is documented in their config docs — the docs wording is imprecise however:

By default it now passes your full environment to those subprocesses.

But further down, you can see an ignore_default_excludes option that has default of false with comment:

When false, Codex removes any var whose name contains KEY, SECRET, or TOKEN (case-insensitive) before other rules run.

making the previous note that "full environment" is passed in "by default", incorrect.

TL;DR

[shell_environment_policy]
ignore_default_excludes = true

should do it.

nothing in this issue works consistently.

having issues on fish!

from fish, i enter zsh, then it finds my shit.
in fish, codex does not find my shit :(
(no path inheritance)

[shell_environment_policy]
inherit = "all"
ignore_default_excludes = true
experimental_use_profile = true

@andreagrandi

I encountered a similar issue when running Codex in a container environment. I injected some specific environment variables each time I called it, but Codex seemed not to actively read the environment variables to perform the expected actions, such as using the GITHUB_TOKEN to call the API. Initially, I resolved this issue by:

Explicitly stating in the prompt that Codex can read environment variables to do something

However, later I found that Codex seems to be able to explicitly set the environment variable policy in the configuration file config.toml: https://github.com/openai/codex/blob/main/docs/config.md#shell_environment_policy

After configuring it according to this method, the issue was resolved.

Just chiming in that I ran into this (codex running a Go test which requires an env variable st). inherit = "all" did not work. I used set={... } in the codex config file, which worked (but obviously that isn't a long term sol'n to keep this in sync with my normal env variable setup).

In general codex security policy and principles are extremely frustrating -- I end up disabling ~all of it so I can actually work, and it still bites me!

@cypriss

Just chiming in that I ran into this (codex running a Go test which requires an env variable st). inherit = "all" did not work. I used set={... } in the codex config file, which worked (but obviously that isn't a long term sol'n to keep this in sync with my normal env variable setup). In general codex security policy and principles are extremely frustrating -- I end up disabling ~all of it so I can actually work, and it still bites me!

Similar situation, in my agent project, I integrated Claude Code CLI, Codex CLI and Gemini CLI. So Codex has been encountering various issues, such as the environment variable policy, config file, MCP, etc.

So, looking at the thing - codex seems to prepend a _LOT_ of things to the path - it does preserve it, but prepends

/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/
usr/appleinternal/bin:/opt/pmk/env/global/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:~/.dotnet/tools:/var/folders/_y/x2bbjyps5831190g955y91_h0000gn/T/.tmpZ800wO:/Users/mickg10/.nvm/versions/node/v25.1.0/lib/node_modules/@openai/codex/vendor/aarch64-apple-darwin/
path

Any idea how to turn that off?

(aesthetic) mickg10@Mac.mickg.net ~/src/improved_aesthetic-predictor 7088 > cat ~/.codex/config.toml; echo $PATH; (export BAR=1234; export PATH=FOO:$PATH; codex -s danger-full-access --dangerously-bypass-approvals-and-sandbox -c model_reasoning_effort="high" -m gpt-5.1-codex --enable web_search_request 'Print me PATH env var and the BAR env var')
tui = { theme = { name = "dark-zen-garden" } }
model = "gpt-5.1-codex"
model_reasoning_effort = "high"

[tools]
websearch = true

features.web_search_request = true

tools.view_image = true

[shell_environment_policy]
inherit = "all"
ignore_default_excludes = true
experimental_use_profile = true

/Users/mickg10/miniconda3/envs/aesthetic/bin:/Users/mickg10/miniconda3/condabin:/Users/mickg10/.nvm/versions/node/v25.1.0/bin:/Users/mickg10/.cargo/bin:/Users/mickg10/.bun/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/pmk/env/global/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:~/.dotnet/tools:/opt/homebrew/opt/fzf/bin
╭──────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.58.0) │
│ │
│ model: gpt-5.1-codex high /model to change │
│ directory: ~/src/improved_aesthetic-predictor │
╰──────────────────────────────────────────────────╯

To get started, describe a task or try one of these commands:

/init - create an AGENTS.md file with instructions for Codex
/status - show current session configuration
/approvals - choose what Codex can do without approval
/model - choose what model and reasoning effort to use
/review - review any changes and find issues

› Print me PATH env var and the BAR env var

• Ran echo "PATH=$PATH"; echo "BAR=$BAR"
└ PATH=/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/
usr/appleinternal/bin:/opt/pmk/env/global/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:~/.dotnet/tools:/var/folders/_y/x2bbjyps5831190g955y91_h0000gn/T/.tmpZ800wO:/Users/mickg10/.nvm/versions/node/v25.1.0/lib/node_modules/@openai/codex/vendor/aarch64-apple-darwin/
path:FOO:/Users/mickg10/miniconda3/envs/aesthetic/bin:/Users/mickg10/miniconda3/condabin:/Users/mickg10/.nvm/versions/node/v25.1.0/bin:/Users/mickg10/.cargo/bin:/Users/mickg10/.bun/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/fzf/bin
BAR=1234

─ Worked for 6s ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• PATH=/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/
usr/appleinternal/bin:/opt/pmk/env/global/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/local/share/dotnet:~/.dotnet/tools:/var/folders/_y/x2bbjyps5831190g955y91_h0000gn/T/.tmpZ800wO:/Users/mickg10/.nvm/versions/node/v25.1.0/lib/node_modules/@openai/codex/vendor/aarch64-apple-darwin/
path:FOO:/Users/mickg10/miniconda3/envs/aesthetic/bin:/Users/mickg10/miniconda3/condabin:/Users/mickg10/.nvm/versions/node/v25.1.0/bin:/Users/mickg10/.cargo/bin:/Users/mickg10/.bun/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/fzf/bin
BAR=1234

❌

[shell_environment_policy]
inherit = "all"
experimental_use_profile = true
ignore_default_excludes = true

[mcp_servers.firecrawl-mcp]
command = "pnpm"
args = ["dlx", "firecrawl-mcp"]

[mcp_servers.firecrawl-mcp.env]
FIRECRAWL_API_KEY = "${FIRECRAWL_API_KEY}"

For anyone having issues making their MCP server configs read environment variables, all of the above will NOT allow your MCP servers to read env vars, and you'll get something like this from the REPL when attempting to do so:

I tried to scrape the guide with Firecrawl, but the tool returned Unauthorized: Invalid token.

[...]
Attempt summary: Firecrawl scrape failed due to invalid credentials, so no page content was captured.

Instead, you'll need to _simply_ do it this way, according to the official docs.

✅

[mcp_servers.firecrawl-mcp]
command = "pnpm"
args = ["dlx", "firecrawl-mcp"]
env_vars = ["FIRECRAWL_API_KEY"]

... which would lead the desired result:

Called firecrawl-mcp.firecrawl_scrape({"url":"https://discussions.apple.com/thread/253509136?sortBy=rank","formats":["markdown"],"onlyMainContent":true})
  └ {"markdown": "􀂎Go back to my question\n\n# Silver dots all over the screen on MacBook Pro which goes away on cleaning with microfibre\n\nHi I bought a MacBook Pro 14 2021 let week and
        today I noticed some silver dots (around 40 of them, picture attached) all over the screen. On rubbing with a microfibre, they seemed to go away. But I am curious as to why this was
        caused, I have read on other threads that the retina coating starts coming off.\n\n![](https://discussions.apple.com/content/attachment/b250e269-cc68-4584-919c-
        03bde57e8d50)\n\n\nPosted on Dec 27, 2021 10:34 PM\n\n\n\n􀉿\n(16)\n\nUpvote if this is a clear question\n\n􀊁\n\nDownvote if this question isn’t clear\n\n􀉻\n\nMe too (153)\nMe too\nMe
        too (153)\nMe tooReply\n\n\nPosted on Dec 28, 2021 3:55 AM\n\n\n\nWith that many, do they have a pattern that mirrors the keys on your keyboard? If so, the keys are touching your
        screen lightly when you close the lid. .

G

G

Refer to the shell environment policy advanced configuration options.

I still can't get any of these options to work. I'm on fish shell if that matters. Becoming convinced my best bet is to create a whole new linux user with the bash profile I need.

Following up here rather than opening a duplicate — this still reproduces on codex-cli 0.139.0 (macOS, arm64), and there are a couple of angles I don't think were covered in the original report that I'd like to add as data points:

1. It persists even under --sandbox danger-full-access / full-access. Once a user has explicitly opted out of sandboxing, the stripped environment is genuinely surprising: agent-invoked tools still don't see HOME, DOCKER_HOST, PATH additions, or cloud-credential env. I understand from #1249 that the scrubbing is intentional secret-hygiene, but the interaction with danger-full-access (where the user has already accepted the risk) feels like it warrants either inheriting by default at that level, or at least a prominent doc note.

2. The failure is silent and gets misattributed. docker ps, gh auth status, aws sts get-caller-identity, ssh, etc. fail with EACCES / "cannot connect" / "not logged in" because their config/socket env is missing — and nothing tells the user (or the model) that Codex removed the env. The model then frequently "diagnoses" a non-existent Docker/auth problem and goes down the wrong path. A one-line diagnostic ("Codex removed N environment variables under shell_environment_policy; see <docs>") when a command fails consistent with stripped env would save a lot of confusion.

3. It bites the codex app-server path too, not just the TUI. A third-party client spawning codex app-server must know to pass -c shell_environment_policy.inherit=all or host tooling is broken out of the box. This isn't obvious from the app-server docs.

Repro (0.139.0):

1. Default config (no shell_environment_policy), run with --sandbox danger-full-access (or the app-server equivalent).
2. Ask the model to run a host tool that needs env, e.g. docker ps (needs DOCKER_HOST/HOME) or gh auth status (needs HOME).
3. It fails with EACCES / missing-config.
4. Add -c shell_environment_policy.inherit=all → the same tools work. (Several commenters above note inherit="all" alone wasn't always enough and that set = { … } was also needed, and that PATH is still aggressively rewritten — would be good to confirm the intended behavior there.)

Suggested resolutions (any one): inherit full env by default under danger-full-access; emit a diagnostic when a command fails consistent with stripped env; or document the danger-full-access × shell_environment_policy interaction and the inherit=all recommendation for app-server integrations.

Related: #22023 (include-allowlist request), #18248 (Windows analog: missing APPDATA/etc. breaks dotnet/NuGet/git). The in-progress "environments v2" refactor (#27433, #27498, #27696, #27709, …) reworks env resolution but, as of 0.140, doesn't appear to change the default inherit behavior for host tools.