Why

shell_zsh_fork already provides stronger guarantees around which executables receive elevated permissions. To reuse that machinery from unified exec without pushing Unix-specific escalation details through generic runtime code, the escalation bootstrap and session lifetime handling need a cleaner boundary.

That boundary also needs to be safe for long-lived sessions: when an intercepted shell session is closed or pruned, any in-flight approval workers and any already-approved escalated child they spawned must be torn down with the session, and the inherited escalation socket must not leak into unrelated subprocesses.

What Changed

• Extracted a reusable EscalationSession and EscalateServer::start_session(...) in shell-escalation so callers can get the wrapper/socket env overlay and keep the escalation server alive without immediately running a one-shot command.
• Documented that EscalationSession::env() and ShellCommandExecutor::run(...) exchange only that env overlay, which callers must merge into their own base shell environment.
• Clarified the prepared-exec helper boundary in core by naming the new helper APIs around ExecRequest, while keeping the legacy execute_env(...) entrypoints as thin compatibility wrappers for existing callers that still use the older naming.
• Added a small post-spawn hook on the prepared execution path so the parent copy of the inheritable escalation socket is closed immediately after both the existing one-shot shell-command spawn and the unified-exec spawn.
• Made session teardown explicit with session-scoped cancellation: dropping an EscalationSession or canceling its parent request now stops intercept workers, and the server-spawned escalated child uses kill_on_drop(true) so teardown cannot orphan an already-approved child.
• Added UnifiedExecBackendConfig plumbing through ToolsConfig, a shell::zsh_fork_backend facade, and an opaque unified-exec spawn-lifecycle hook so unified exec can prepare a wrapped zsh -c/-lc request without storing EscalationSession directly in generic process/runtime code.
• Kept the existing shell_command zsh-fork behavior intact on top of the new bootstrap path. Tool selection is unchanged in this PR: when shell_zsh_fork is enabled, ShellCommand still wins over exec_command.

Verification

• cargo test -p codex-shell-escalation
  • includes coverage for start_session_exposes_wrapper_env_overlay
  • includes coverage for exec_closes_parent_socket_after_shell_spawn
  • includes coverage for dropping_session_aborts_intercept_workers_and_kills_spawned_child
• cargo test -p codex-core shell_zsh_fork_prefers_shell_command_over_unified_exec
• cargo test -p codex-core --test all shell_zsh_fork_prompts_for_skill_script_execution

Stack created with Sapling. Best reviewed with ReviewStack.

• refactor: route zsh-fork through unified exec #13432
• -> refactor: prepare unified exec for zsh-fork backend #13392