Codex desktop shell tool calls do not inherit terminal auth/session environment

Open 💬 2 comments Opened Mar 9, 2026 by rungchan2

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.305.950(863)

What subscription do you have?

plus

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Summary

Commands that succeed in my normal terminal fail when executed by Codex desktop because the command execution environment does not inherit the same auth/session environment.

Repro

In a normal terminal, run:<br>supabase db push<br>This works.
In Codex desktop, ask Codex to run:<br>supabase db push
Codex fails with:<br>Access token not provided. Supply an access token by running supabase login or setting the SUPABASE_ACCESS_TOKEN environment variable.

Expected

Codex command execution should inherit the same shell/session/auth environment as my terminal, or clearly document/isolate that it does not.

Actual

Codex can see the repo and linked Supabase project, but shell commands do not see the same auth state as my terminal session.

Additional notes

This looks related to shell/env handling issues like:
CLI-1536
CLI-260
In my case, the mismatch affects auth/session propagation, not just PATH/default shell.
I also observed npm run update-type fail for the same reason because the redirected shell command runs in the Codex execution environment rather than my working terminal session.

What steps can reproduce the bug?

Open a project in Codex Desktop where Supabase is already linked.
In a normal terminal on the same machine, run supabase db push and confirm it works.
In Codex Desktop, ask Codex to run supabase db push in the same workspace.
Observe that Codex fails with: Access token not provided. Supply an access token by running supabase login or setting the SUPABASE_ACCESS_TOKEN environment variable.
Optionally run npm run update-type from Codex as well and observe the same auth-related failure, even though the equivalent Supabase command works in the normal terminal.

What is the expected behavior?

Commands executed by Codex Desktop should inherit the same shell/auth environment as the user’s normal terminal session, or behave consistently enough that commands which work in the user terminal also work when Codex runs them. In this case, if supabase db push and supabase gen types work in my terminal, they should also work when run by Codex in the same workspace.

Additional information

No response

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#13160
#13556
#13566
#14016
#13426

Powered by Codex Action

dataders · 4 months ago

Seeing another concrete manifestation of this in Codex Desktop on macOS: signed git operations fail in worktree shells because SSH_AUTH_SOCK is not inherited.

What I observed:

In a Codex shell opened from the main repo checkout, SSH_AUTH_SOCK is set and ssh-add -l shows my loaded ED25519 key.
In a Codex shell opened from a worktree for the same repo, SSH_AUTH_SOCK is empty.
As a result, git commit -S and signed git rebase fail in the worktree shell because git cannot reach the existing ssh-agent.

I also proved this is environment inheritance, not a git/worktree limitation:

From the main-repo Codex shell, I was able to create a signed commit in a plain non-worktree clone.
From the worktree Codex shell, I ran the same signing flow against that exact same plain clone and it failed.
Same machine, same clone, same signing key config; only the Codex shell environment changed.

In my shell setup, the missing SSH_AUTH_SOCK also triggers ssh-agent bootstrap logic in shell startup, which can repoint a shared socket at a fresh empty agent in a non-interactive shell and make the failure mode even worse.

So this issue seems to affect not just tool-specific auth like Supabase tokens, but also ssh-agent-backed git signing/auth workflows.