Skip to content

refactor: normalize unix module layout for exec-server and shell-escalation#12556

Merged
bolinfest merged 1 commit intomainfrom
pr12556
Feb 23, 2026
Merged

refactor: normalize unix module layout for exec-server and shell-escalation#12556
bolinfest merged 1 commit intomainfrom
pr12556

Conversation

@bolinfest
Copy link
Copy Markdown
Collaborator

@bolinfest bolinfest commented Feb 23, 2026

Why

Shell execution refactoring in exec-server had become split between duplicated code paths, which blocked a clean introduction of the new reusable shell escalation flow. This commit creates a dedicated foundation crate so later shell tooling changes can share one implementation.

What changed

  • Added the codex-shell-escalation crate and moved the core escalation pieces (mcp protocol/socket/session flow, policy glue) that were previously in exec-server into it.
  • Normalized exec-server Unix structure under a dedicated unix module layout and kept non-Unix builds narrow.
  • Wired crate/build metadata so shell-escalation is a first-class workspace dependency for follow-on integration work.

Verification

  • Built and linted the stack at this commit point with just clippy.

Stack created with Sapling. Best reviewed with ReviewStack.

@bolinfest bolinfest changed the base branch from main to pr12555 February 23, 2026 07:39
@bolinfest bolinfest force-pushed the pr12556 branch 3 times, most recently from 056ddb7 to c3df4f8 Compare February 23, 2026 08:25
@bolinfest bolinfest changed the title feat: split core business logic from exec-server to shell-escalation refactor: normalize unix module layout for exec-server and shell-escalation Feb 23, 2026
bolinfest added a commit that referenced this pull request Feb 23, 2026
## Why
The current escalate path in `codex-rs/exec-server` still had policy
creation coupled to MCP details, which makes it hard to reuse the shell
execution flow outside the MCP server. This change is part of a broader
goal to split MCP-specific behavior from shared escalation execution so
other handlers (for example a future `ShellCommandHandler`) can reuse it
without depending on MCP request context types.

## What changed
- Added a new `EscalationPolicyFactory` abstraction in `mcp.rs`:
  - `crate`-relative path: `codex-rs/exec-server/src/posix/mcp.rs`
-
https://github.com/openai/codex/blob/main/codex-rs/exec-server/src/posix/mcp.rs#L87-L107
- Made `run_escalate_server` in `mcp.rs` accept a policy factory instead
of constructing `McpEscalationPolicy` directly.
-
https://github.com/openai/codex/blob/main/codex-rs/exec-server/src/posix/mcp.rs#L178-L201
- Introduced `McpEscalationPolicyFactory` that stores MCP-only state
(`RequestContext`, `preserve_program_paths`) and implements the new
trait.
-
https://github.com/openai/codex/blob/main/codex-rs/exec-server/src/posix/mcp.rs#L100-L117
- Updated `shell()` to pass a `McpEscalationPolicyFactory` instance into
`run_escalate_server`, so the server remains the MCP-specific wiring
layer.
-
https://github.com/openai/codex/blob/main/codex-rs/exec-server/src/posix/mcp.rs#L163-L170

## Verification
- Build and test execution was not re-run in this pass; changes are
limited to `mcp.rs` and preserve the existing escalation flow semantics
by only extracting policy construction behind a factory.




---
[//]: # (BEGIN SAPLING FOOTER)
Stack created with [Sapling](https://sapling-scm.com). Best reviewed
with [ReviewStack](https://reviewstack.dev/openai/codex/pull/12555).
* #12556
* __->__ #12555
Base automatically changed from pr12555 to main February 23, 2026 08:31
@bolinfest bolinfest merged commit 5221575 into main Feb 23, 2026
60 of 66 checks passed
@bolinfest bolinfest deleted the pr12556 branch February 23, 2026 17:28
@github-actions github-actions bot locked and limited conversation to collaborators Feb 23, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants