jif bd2968a4db Carry sandbox intent to remote exec servers (#29108) ...

## What changed

PR #29099 stopped sending the orchestrator's concrete sandbox wrapper to
a remote exec-server. Remote commands now arrive as plain native argv.

This PR adds the next piece: Codex also sends portable sandbox intent
next to that plain argv.

For a remote unified-exec command, the request can now include:

- the canonical permission profile before local workspace-root
materialization
- the sandbox cwd and workspace roots as `PathUri` values
- Windows sandbox settings
- the legacy Landlock setting
- whether managed networking must be enforced

The important part is that symbolic entries such as `:workspace_roots`
stay symbolic while crossing the boundary. The executor can then bind
them to its own workspace-root paths instead of receiving
orchestrator-local absolute paths.

The data travels through `ExecRequest` into `ExecParams`. Older
exec-servers can still deserialize requests because the new fields have
defaults.

## Why

The orchestrator should not decide how another machine implements
sandboxing.

For example:

- a local macOS Codex would normally build a Seatbelt command
- a remote Linux executor needs a Linux sandbox command instead

The orchestrator now sends the plain command plus the policy it intended
to enforce. A later PR can let the exec-server choose and build the
correct sandbox for its own operating system.

## Important detail

This keeps the portable intent separate from the local `SandboxType`.

`SandboxType::None` is ambiguous:

- it can mean the command was explicitly approved to run without a
sandbox
- it can also mean the orchestrator host has no concrete sandbox
implementation available

Those cases are different for remote execution. This PR adds
`sandbox_requested` so an executor can still receive sandbox intent when
the orchestrator cannot build a local wrapper. Explicit unsandboxed
retries still send no sandbox context.

## Behavior today

This PR only transports the intent. The exec-server accepts the new
fields but does not apply them yet.

Remote commands therefore remain unsandboxed after this PR, just as they
are after PR #29099.

## Follow-up

The next PR will make exec-server read this portable intent, bind
symbolic workspace permissions to executor-native roots, choose the
sandbox for its own operating system, build the wrapper locally, and
then spawn the command.

bd2968a4db · 2026-06-21 12:33:21 +02:00

History

..

common

Run fs helper through Windows sandbox wrapper (#28359)

2026-06-17 10:00:42 -07:00

file_system

[codex] exec-server: stream files in chunks (#28354)

2026-06-16 09:50:55 -07:00

exec_process.rs

Carry sandbox intent to remote exec servers (#29108)

2026-06-21 12:33:21 +02:00

file_stream.rs

[codex] exec-server: stream files in chunks (#28354)

2026-06-16 09:50:55 -07:00

file_system_unix.rs

[codex] Use expect in integration tests (#28441)

2026-06-15 21:53:47 -07:00

file_system_windows.rs

Run fs helper through Windows sandbox wrapper (#28359)

2026-06-17 10:00:42 -07:00

health.rs

[codex] Add environment shell info (#26480)

2026-06-04 22:36:25 -07:00

http_client.rs

[2/4] Implement executor HTTP request runner (#18582)

2026-04-22 20:36:34 +00:00

http_request.rs

[2/4] Implement executor HTTP request runner (#18582)

2026-04-22 20:36:34 +00:00

initialize.rs

feat: move exec-server ownership (#16344)

2026-04-10 14:11:47 +01:00

process.rs

Recover exec process stdin writes (#28895)

2026-06-18 19:04:26 +02:00

relay.rs

Carry sandbox intent to remote exec servers (#29108)

2026-06-21 12:33:21 +02:00

websocket.rs

fix(exec-server): reject websocket requests with Origin headers (#24947)

2026-05-28 14:44:14 -07:00