Configurable default login shell for shell tools

[pikkili]

Summary
Adds [shell].default_login to control the default login‑shell behavior for shell, local_shell, and shell_command when a tool call does not
specify login. Explicit login=true|false in the tool call always overrides the config.

Motivation
In curated environments, PATH and other env vars are intentionally inherited. The current default login shell can reinitialize PATH and
override the inherited environment. A config‑level default lets users preserve the inherited environment when needed while keeping existing
behavior unchanged if the option is absent.

Behavior

• Backwards‑compatible default: If [shell].default_login is not set, the default remains true (login shells).
• Explicit tool calls win: login=true|false in tool arguments always overrides config.
• Applies to: shell, local_shell, and shell_command.
• Unified exec: snapshot behavior is unchanged; when a snapshot exists and login is omitted, it still defaults to non‑login. Otherwise it
  uses default_login.

Docs (external)
In‑repo docs are link‑only (per #8662). Please update external docs:

Config reference (https://developers.openai.com/codex/config-reference)

[shell]
default_login = true

default_login (boolean, default true): When true, shell commands run with login semantics (e.g., bash -lc). When false, Codex avoids login
shells by default. Explicit login values on a tool call still override this default.

Config sample (https://developers.openai.com/codex/config-sample)

[shell]

Default when tool calls omit login. Default: true

default_login = true

Tests

• just fmt
• just fix -p codex-core
• cargo test -p codex-core

Issue

• Login shells override inherited PATH in curated environments; need configurable default #8922

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[pikkili]

I have read the CLA Document and I hereby sign the CLA

[pikkili]

recheck

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1924aee486

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[etraut-openai]

@pikkili, thanks for the contribution. I'm not sure this is the right approach to fix this problem, but I will discuss with my colleagues. In the meantime, please fix the CI failures.

[pikkili]

Thanks for the review and for flagging the approach. I pushed follow‑up commits to address the CI failures and will keep an eye on the checks.

[etraut-openai]

@pikkili, there are some new merge conflicts. Could you please resolve those? Thanks!

[pikkili]

Resolved the conflict in codex-rs/core/src/config/mod.rs, rebased on origin/main, and pushed the updated branch. Fast checks re‑run locally.

[etraut-openai]

Thanks for the contribution. I've discussed with my colleagues, and we've decided to pass on this PR. We don't think this is the right long-term solution for this problem.

[pikkili]

Thanks @etraut-openai for the review and for discussing internally. We’d appreciate guidance on the preferred long‑term approach. At Oracle we use ADE (our internal VCS; toolchain paths are set when entering an ADE view), but "bash -lc" reinitializes PATH and Codex can no longer see the ADE toolchain, so it can’t run builds/tests to verify its own changes. As a result we frequently see non‑compilable changes that require developer intervention to validate, and this also blocks using Codex reliably in our automation workflows. We tried a workaround by adding explicit instructions in AGENTS.md to always use non‑login shells, but that isn’t reliable in long or complex sessions. We want to align with Codex’s intended direction. Thank you for your time.

[etraut-openai]

We haven't settled on a concrete direction here. We've had reports of numerous issues relating to login shells, and many of the solutions we've explored have bad side effects (they fix some issues but break other use cases). We're exploring whether there's a more general solution that can be baked into the model intelligence. In the meantime, we don't want to paint ourselves into a corner by exposing hard-coded configuration knobs like the one you've proposed in this PR.

Thanks for explaining your use case. That's helpful. Here are some potential ideas for an intermediate workaround.

1. Make your ADE environment load on the login shell. If your devs are mostly using zsh, for example, you could modify .bash_profile to initialize env variables for the current ADE view.
2. Wrap your builds/tests with a script that establishes the ADE view, and have codex run that script rather than calling the build/tests directly.
3. If your tools/tests are located relative to the view's base directory, use absolute paths rather than relative paths to avoid or limit reliance on PATH when invoking them.
4. Make use of env var forwarding in the codex config.toml. This won't fix the issue with PATH because that will be overwritten by the login shell, but it provides a way to pass information other than PATH.

I don't know enough about your particular configuration or workflow to say which of these might be viable or palatable, but I'm hoping that there's an idea here that you can use.

[pikkili]

Thank you, @etraut-openai. If you have (or plan to create) an issue tracker, please keep us in the loop so we can track this internally as well.

At this point, we have explored several workarounds, but none are particularly compelling:

• We can force Codex to use a non-login shell by explicitly prompting for it. However, asking everyone internally to remember and consistently include this in prompts does not scale well.
• Using AGENTS.md as a guardrail to force non-login shells works initially, but breaks down as context grows or tasks become more involved.
• ADE views differ from Git-based workflows. Entering a view requires executing an ADE command, which sets up product- and branch-specific toolchains and environment variables. Codex is typically run from within a view to modify the codebase, but it cannot re-enter or reinitialize the view from inside an existing view. Re-sourcing the underlying scripts that ADE uses is messy and highly product/branch-specific.
• There is no single, generic location for all tools; paths vary by product and branch.

Summary:
In curated environments like ours, PATH inheritance is critical. The available workarounds do not look very promising at this time.

As a related note, we also ran into additional issues when building from within Codex due to process hardening introduced in newer versions. Codex now sanitizes loader-related environment variables (LD_) at process startup as a defense-in-depth measure. This removes LD_LIBRARY_PATH before any build tools execute. In contained environments like ours, we have historically relied on libraries provided via LD_ paths, so this change is particularly impactful.

[etraut-openai]

Thanks for the details.

I have some good news for you about the environment variable (LD_, etc.) sanitization. We've decided to remove that logic. It will be gone in the next release.

[pikkili]

Thank you @etraut-openai — if I may ask one more question:

In production automation flows (diagnose → fix → build/test → submit PR → respond to review → merge), what split do you recommend between:
• Codex running the full loop end-to-end (invoking builds/tests, polling, retries, artifact capture, etc.), vs
• Codex as the intelligence layer, with an external orchestrator handling deterministic execution and only calling Codex for reasoning-heavy steps (diagnosis, patch generation, interpreting failures, deciding next actions)?

Internally we’ve been debating simplicity (one Codex does everything) vs determinism/cost/reliability (orchestrator owns execution). Curious what your team’s recommended best practice is.