preserve shell session state across commands for env-sensitive workflows

Resolved 💬 1 comment Opened Apr 19, 2026 by 0xdeafbeef Closed May 31, 2026

What variant of Codex are you using?

codex-cli 0.121.0

What feature would you like to see?

Codex should support a persistent interactive shell context that can be reused across commands within a session, so shell state is preserved when workflows depend on it.

Today, separate shell/exec calls behave like fresh shells, which breaks common development flows that rely on environment or shell-local state carrying forward. This makes Codex awkward for workflows such as:

  • source .env (I personally had 100s of set -a; source .env; set +a; ... commands in ~/.codex/sessions/)
  • . venv/bin/activate
  • conda activate
  • nix develop
  • temporary PATH, JAVA_HOME, KUBECONFIG, AWS_PROFILE, or similar env changes

What it would look like:

  • When a workflow depends on shell state, Codex should keep using that same shell instead of starting a fresh one for each command.
  • This should preserve state between calls, using the same mechanism background terminal uses right now. For example, something like exec_command_in(id, command).
  • The UI should make it clear when commands are running inside a reused shell session, and there should be an explicit way to reset or discard that session.

You can kind of do it now with background terminal, but it is a bad fit for normal command execution and uses more tokens than it should because of polling.

I’m not fully sure about tradeoffs here. Maybe it hurts model reliability, because explicit state is better than implicit mutable env. But for clearly stateful flows, current behavior feels worse.

Additional information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗