Codex does not inherit zsh aliases from .zshrc during command execution, while other shell init state is inherited

What version of Codex CLI is running?

codex-cli 0.114.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.19.10-1-cachyos x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Cursor IDE terminal on Linux KDE Plasma (but applies to any terminal emulator)

What issue are you seeing?

When Codex runs commands in zsh, it inherits my exported environment correctly, but it does not inherit aliases defined in ~/.zshrc.

This breaks setups where a command is intentionally overridden via alias. In my case, I use 1Password shell plugin integration for GitHub CLI, with:

alias gh="op plugin run -- gh"

Claude Code in my environment sees this alias correctly, but Codex does not.
Inside Codex, gh resolves to the real binary instead of the alias.

Important detail: this seems specific to aliases. Other shell init state is inherited correctly, including exports and eval-based setup.

Examples:

• PATH/custom environment is inherited
• fnm-related environment is inherited
• exported variables are inherited
• alias definitions from ~/.zshrc are not inherited

Because of this, commands that depend on aliased wrappers behave differently in Codex than in my normal terminal or in Claude.

Inside Codex:

echo $0
# /usr/bin/zsh

echo $-
# 569X

type gh
# gh is /usr/bin/gh

Inside Claude:

echo $0
# /usr/bin/zsh

echo $-
# 569JNRXghkl

type gh
# gh is an alias for op plugin run -- gh

Also relevant:

• codex is installed as a global npm package under fnm
• claude is installed at ~/.local/bin/claude

Paths on my machine:

which codex
# /run/user/1000/fnm_multishells/.../bin/codex

which claude
# /home/pavlec/.local/bin/claude

A workaround is to define a shell function in ~/.zshenv instead of an alias in ~/.zshrc, for example:

gh() {
  op plugin run -- gh "$@"
}

When I move the override there, Codex works. That suggests Codex is reading ~/.zshenv but not preserving or sourcing alias state from ~/.zshrc.

What steps can reproduce the bug?

1. Use zsh as the shell.
2. Define an alias in ~/.zshrc, for example:

alias gh="op plugin run -- gh"

1. Ensure the alias works in a normal terminal: type gh
2. Start Codex in a project and ask it to run:

echo $0
echo $-
type gh

1. Observe that: type gh returns gh is /usr/bin/gh

1. Compare with another tool/session where the alias is present.
2. Move the same override to ~/.zshenv as a function:

gh() {
  op plugin run -- gh "$@"
}

1. Restart Codex and observe that gh now works.

What is the expected behavior?

Codex command execution should either:

1. inherit the same shell alias/function setup that the user expects from their configured zsh environment, or
2. clearly document which shell startup files are used for command execution and which are ignored

At minimum, I would expect behavior to be consistent and documented.

Since exports/evals are inherited but aliases are not, the current behavior is surprising and hard to debug.

Additional information

This is especially noticeable with auth/tooling wrappers such as:

• 1Password shell plugin
• gh wrapped through op plugin run -- gh

The issue does not appear to be that Codex cannot run the wrapped command at all. If I define the wrapper in ~/.zshenv, it works. That makes this look more like shell init / alias loading behavior than a direct sandbox restriction.