refactor: route zsh-fork through unified exec

[bolinfest]

Why

When unified_exec and shell_zsh_fork are enabled together, unified-exec sessions need to stay on the configured zsh-fork binary so exec interception remains reliable for approvals, execpolicy, and escalation behavior.

In practice, those sessions could drift away from the configured zsh_path in a few ways:

• routing could fall back to the wrong tool surface when both features were enabled
• explicit exec_command.shell overrides could request a different shell
• nested exec zsh calls could hop onto the host zsh
• privileged login-shell sessions could surface startup helpers like /usr/libexec/path_helper as separate escalated execs
• privileged exec_command sessions could let later write_stdin subcommands inherit that broader privilege instead of dropping back to turn-default policy
• zsh-fork escalation-session resources could stay resident until the model polled again

That weakens the guarantees the zsh-fork path is supposed to provide and makes privileged interactive sessions much noisier than intended.

What Changed

• Kept zsh-fork sessions on exec_command / unified exec when both features are enabled, and hid the shell parameter from the exec_command schema when the session is actively using zsh-fork (core/src/tools/spec.rs, core/src/tools/handlers/unified_exec.rs).
• In active zsh-fork unified-exec sessions, ignore model-provided shell overrides and always launch the configured zsh_path (core/src/tools/handlers/unified_exec.rs).
• Replaced permissive shell-shape scanning with deterministic parsing of the original shell argv (program, -c / -lc, script) before preparing the zsh-fork unified-exec path (core/src/tools/runtimes/shell/unix_escalation.rs, core/src/tools/runtimes/shell/zsh_fork_backend.rs, core/src/tools/runtimes/unified_exec.rs).
• For privileged unified-exec zsh-fork launches, build an exact intercepted inner zsh -c ... target instead of heuristically matching later startup execs. When a matching shell snapshot exists for a login-shell request, that inner command now sources the snapshot, reapplies explicit env overrides, and then runs the original script. This preserves login-derived shell state without rerunning startup helpers under zsh-fork interception (core/src/tools/runtimes/mod.rs, core/src/tools/runtimes/shell/unix_escalation.rs).
• Kept nested intercepted zsh execs on zsh-fork by:
  • recognizing approved host zsh installations
  • forcing escalation when an intercepted exec targets host zsh instead of the configured zsh_path
  • rewriting that intercepted program path back to the configured zsh_path
    (core/src/tools/runtimes/shell/unix_escalation.rs).
• Kept skill lookup pinned to the turn cwd and re-read execpolicy for intercepted execs so approved amendments continue to apply to later matching subcommands in the same session (core/src/tools/runtimes/shell/unix_escalation.rs).
• Ensured write_stdin subcommands in a privileged zsh-fork unified-exec TTY fall back to turn-default sandbox policy unless separately allowed, while still honoring matching prefix_rule() approvals (core/src/tools/runtimes/shell/unix_escalation.rs, core/tests/suite/unified_exec.rs).
• Released zsh-fork escalation-session resources when unified-exec processes exit, even if the model never polls the session again (core/src/unified_exec/process.rs, core/src/tools/runtimes/shell/zsh_fork_backend.rs).
• Expanded coverage for the routed unified-exec zsh-fork path:
  • app-server v2 turn-start coverage, including interrupt cleanup and the login-startup-helper regression (app-server/tests/suite/v2/turn_start_zsh_fork.rs)
  • approval / amendment behavior (core/tests/suite/approvals.rs)
  • skill prompt and turn-cwd behavior (core/tests/suite/skill_approval.rs)
  • interactive unified-exec behavior, including executable-path assertions, nested zsh rewrite coverage, and the privileged-write_stdin sandbox regression (core/tests/suite/unified_exec.rs)
  • unit tests for shell parsing, snapshot-backed exact matching, shell-override handling, and zsh rewrite predicates (core/src/tools/handlers/unified_exec_tests.rs, core/src/tools/runtimes/shell/unix_escalation_tests.rs)
• Added Windows-safe #[cfg(unix)] usage around zsh-fork-only integration coverage.

Verification

• cargo test -p codex-core build_exact_match_zsh_fork_reexec --lib
• cargo test -p codex-core maybe_wrap_shell_lc_with_snapshot --lib
• cargo test -p codex-core --test all unified_exec_zsh_fork_write_stdin_reverts_to_default_sandbox_and_honors_prefix_rule
• cargo test -p codex-app-server --test all turn_start_shell_zsh_fork_login_startup_helper_does_not_prompt_separately_v2

Manual Testing

Run Codex built from source with both features enabled as follows:

just codex --enable unified_exec --enable shell_zsh_fork --config zsh_path=$(realpath codex-rs/app-server/tests/suite/zsh)

Then ask Codex to do something like:

Start a new instance of a shell using exec_command where it just runs `ls` but keep it around.

Then tell it:

Run python3 in the shell. Once the REPL starts, run `import os; print(os.getpid())` and tell me what you get.

In my case, it replied with:

python3 started in the existing shell session, and import os; print(os.getpid()) printed:

55692

Then over in a plain shell, I checked pstree and confirmed that the Python process was still running under the configured zsh-fork shell rather than the host shell.

[jif-oai]

I think the exact match will create some issues... what if you don't have a shell snapshot available for example? Then we can still have a -lc

This will basically break the pre-approved path

[jif-oai]

this changes the contract of the shell snapshot. It means you will restore something coming from before the shell_snapshot on top of the shell_snapshot