{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreifyk5gpw5vh56pu56bqummxqbscih7zkedhierjjs6454sbfpkoli",
"uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mi4mnnx6xgx2"
},
"path": "/t/how-to-allow-codex-connection-to-docker-in-local-environment/1373567#post_4",
"publishedAt": "2026-03-28T10:48:24.000Z",
"site": "https://community.openai.com",
"textContent": "The short answer is: Codex App is not using your full login-shell environment.\n\nAnd likely on your machine, the app’s command runner is starting a zsh that is neither login nor interactive. In my case, I verified that in the app session: [[ -o login ]] is no and [[ -o interactive ]] is no. That means PATH changes from ~/.zprofile and~/.zshrc are not applied, while the lightweight exports in ~/.zshenv are.\n\nThat matches what I observed:\n\n * App/non-login PATH includes only entries from .zshenv, like Homebrew, pnpm, Flutter, .local/bin, .gem/bin.\n\n * A real login shell (zsh -lc) adds the missing entries from .zprofile, like JetBrains Toolbox, .dotnet, and Android SDK paths.\n\n * .zshrc would add even more interactive-only tooling like nvm, opam, lms, etc.\n\n\n\n\nSo the reason PATH looks “not propagated” is usually a combination of two things on macOS:\n\n 1. GUI apps inherit environment from launchd, not from your Terminal session.\n\n 2. Codex’s runner is effectively using a non-login shell, so it does not read the files where you add a lot of your PATH.\n\n\n\n\nIf you want the app to reliably see a tool, the practical fixes are:\n\n * Put essential, non-interactive PATH exports in ~/.zshenv .\n\n * Or launch Codex from a shell that already has the right env.\n\n * Or set machine/session env for GUI apps via launchctl setenv.\n\n * Or use absolute paths for tools that must always resolve.\n\n\n\n\nWhile the Codex App behaviour is really odd, you can ask it to adjust the env variables for you, by sharing the context from this thread.",
"title": "How to allow Codex connection to Docker in local environment?"
}