Report remote sandbox denials semantically

[jif-oai]

Why

#29113 moved remote sandbox setup and enforcement to the exec server. That gives the executor ownership of the platform-specific work: a Linux executor chooses and runs a Linux sandbox even when the Codex orchestrator is running on macOS or Windows.

It also means the orchestrator no longer knows which concrete sandbox the executor selected. When that sandbox blocks a remote command, the orchestrator currently sees only a failed process and can treat the denial as an ordinary command failure. The existing sandbox approval and retry path is then skipped.

This PR lets the executor report one portable fact:

This command probably failed because the executor sandbox blocked it.

The executor keeps its concrete sandbox type private. The protocol sends only the semantic result.

Example

Suppose a local macOS Codex session asks a Linux devbox to write outside the allowed workspace.

Before this PR:

Linux sandbox blocks the write
    -> remote process exits with "Permission denied"
    -> local orchestrator sees an ordinary command failure
    -> the normal sandbox approval and retry path can be skipped

With this PR:

Linux sandbox blocks the write
    -> executor reports sandboxDenied: true
    -> unified exec returns UnifiedExecError::SandboxDenied
    -> the existing approval prompt is shown
    -> an approved retry runs through the existing unsandboxed retry path

What changes

The executor remembers its selected sandbox

The prepared remote process now retains the executor-selected SandboxType. This value never crosses the executor boundary.

Commands started without a sandbox retain SandboxType::None and are never reported as sandbox denials.

The executor uses the existing denial heuristic

The existing local denial heuristic moves from codex-core into the shared codex-sandboxing crate.

When a sandboxed remote process exits, the executor:

1. waits the same short output grace period used by local unified exec;
2. reads the output currently available in the existing retained output buffer;
3. runs the existing heuristic using the exit code and common denial messages;
4. stores the yes/no result before publishing the process exit.

This deliberately matches the old local unified-exec behavior. It does not add a new streaming classifier, another output buffer, or stronger output-retention guarantees.

The protocol reports a portable boolean

process/read gains sandboxDenied:

{
  "exited": true,
  "exitCode": 1,
  "closed": false,
  "sandboxDenied": true
}

The field defaults to false when an older executor omits it. The response does not expose the executor sandbox implementation or executor-native paths.

Unified exec uses the existing error path

The exec-server client carries sandboxDenied into the unified process state. If it is true, unified exec returns the existing SandboxDenied error instead of trying to classify remote output using an orchestrator-side sandbox type.

Remote process exit remains visible as soon as the process exits. This PR does not wait for stdout or stderr to close and does not change the existing process lifecycle.

Scope

This PR is intentionally limited to matching the existing local unified-exec behavior for the initial command execution path.

It does not add:

• incremental denial tracking across the full output stream;
• new denial handling for commands completed later through write_stdin;
• new guarantees for preserving the semantic flag during the narrow reconnect-recovery race.

Those can be considered separately if the same behavior is added for local execution.

Test coverage

One remote end-to-end integration test covers the complete intended flow:

remote read-only sandbox
    -> denied write
    -> executor reports the denial
    -> Codex requests approval
    -> user approves
    -> retry succeeds on the remote executor

Existing lifecycle coverage continues to verify that remote process exit is reported before late output streams close.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 62bd4e6684

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".