feat(pap-sandbox): wire real IPC pipeline, runtime feature detection, Docker adapter

[toadkicker]

Summary

• Real IPC pipeline: All platform spawners (Linux/BSD/macOS/Windows) write ExecutionContext JSON to child stdin and read ExecutionResult JSON from stdout on exit — no more stubs or let _ = context_json
• Runtime feature detection: detect_runtime() probes actual OS capabilities via os_capabilities::detect() (prctl(PR_GET_SECCOMP) on Linux, probe_mlock() on Unix, etc.) instead of hardcoded #[cfg] booleans
• Docker adapter: DockerSpawner spawns agents as sibling containers via bollard, maps CapabilityPolicy to Docker flags (--network=none, --cap-drop, --read-only, --memory), reads container logs for result
• Worker module: Child-side IPC protocol — reads context from stdin, decrypts query, executes agent, encrypts result, writes ExecutionResult to stdout
• No silent fallbacks: NoopSpawner returns errors, handler_wrapper refuses to fall back to unsandboxed execution on empty results, new_spawner() returns errors when no platform available
• 66 tests across 8 modules including 7 new worker/IPC round-trip tests

Test plan

• All 66 pap-sandbox tests pass locally (Windows)
• CI passes on Linux (seccomp detection, LinuxSpawner compile)
• CI passes on macOS (entitlements detection, MacosSpawner compile)
• Verify Docker adapter compiles on Linux/macOS (bollard cfg-gated)
• Verify new_spawner() returns WindowsSpawner on Windows via job_objects probe
• Verify new_spawner() returns error (not silent noop) when no capabilities detected

🤖 Generated with Claude Code

[greptile-apps]

toadkicker has reached the 50-review limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[github-actions]

Benchmark Regression Report

PAP Protocol Benchmark Regression Check
========================================
Baseline: .bench-baseline/baseline.json
Threshold: 55%

  ed25519_keypair_generation                17.1 µs  (baseline: 19.7 µs, -13.0%)  [ok]
  did_key_derivation                         1.3 µs  (baseline: 1.4 µs, -10.5%)  [ok]
  mandate_create_sign                       20.8 µs  (baseline: 23.1 µs, -10.1%)  [ok]
  mandate_chain_verify_depth3              119.6 µs  (baseline: 148.2 µs, -19.3%)  [ok]
  sd_jwt_issue_5claims                      24.0 µs  (baseline: 26.6 µs, -10.0%)  [ok]
  sd_jwt_verify_disclose_3of5               41.2 µs  (baseline: 50.8 µs, -18.9%)  [ok]
  session_open_full_lifecycle               93.1 µs  (baseline: 102.5 µs, -9.2%)  [ok]
  receipt_create_cosign                     41.6 µs  (baseline: 46.9 µs, -11.1%)  [ok]
  federation_announce_local                 51.7 µs  (baseline: 66.6 µs, -22.4%)  [ok]


P99 Tail-Latency Check
----------------------
Results: target/p99_results.json
Threshold: 50%

  session_open_full_lifecycle(p99)         106.6 µs  (baseline: 500.0 µs, -78.6%)  [ok]
  mandate_chain_verify_depth3(p99)         130.6 µs  (baseline: 480.0 µs, -72.7%)  [ok]
  receipt_create_cosign(p99)                49.7 µs  (baseline: 210.0 µs, -76.3%)  [ok]

All benchmarks within 55% of baseline.

_{Threshold: 10% regression vs baseline from main}

[greptile-apps]

Greptile Summary

This PR wires a real IPC pipeline (stdin/stdout JSON) across all platform spawners, adds runtime capability detection via os_capabilities::detect(), introduces a Docker sibling-container spawner, and hardens the fallback path so empty result_enc is now an error rather than a silent bypass. The native platform spawners (Linux, BSD, macOS, Windows) look correct. The Docker adapter has three P1 defects that would prevent it from working correctly in production.

Confidence Score: 4/5

Safe to merge for native-platform paths; Docker spawner has P1 bugs that must be addressed before Docker-based agent execution can work.

Three P1 issues are isolated to docker.rs: invalid cap-drop names that will fail container creation, container records leaked after successful exit, and an IPC protocol mismatch where the worker reads from stdin but the spawner only passes context via env var. The native spawner paths and security hardening in handler_wrapper.rs are solid.

crates/pap-sandbox/src/platform/docker.rs — all three P1 findings are here.

Important Files Changed

Filename	Overview
crates/pap-sandbox/src/platform/docker.rs	New Docker sibling-container spawner with three P1 bugs: invalid cap-drop names, container records never cleaned up, and IPC mismatch between worker stdin and spawner env var.
crates/pap-sandbox/src/platform/detection.rs	New runtime detection module; sound overall but Docker socket check is gated behind is_in_container(), silently returning Unsupported on bare-metal hosts with Docker but no native sandbox capabilities.
crates/pap-sandbox/src/worker.rs	New child-side IPC worker; correct for native spawners but incompatible with DockerSpawner which passes context via env var and never writes to stdin.
crates/pap-sandbox/src/spawner.rs	Changed new_spawner() from sync to async with runtime feature detection; NoopSpawner now errors instead of silently passing.
crates/pap-sandbox/src/handler_wrapper.rs	Removed silent fallback to unsandboxed execution when result_enc is empty — good security hardening.
Dockerfile	New multi-stage Dockerfile; build silently swallows errors via
apps/papillon/src/lib.rs	Adapted to async new_spawner() by creating a new Tokio runtime; functionally correct but creates a redundant runtime inside Tauri's setup callback.
apps/registry/src/main.rs	Minimal correct change: new_spawner() is now awaited since the function became async.

Sequence Diagram

sequenceDiagram
    participant P as Parent Process
    participant D as detect_runtime()
    participant S as Platform Spawner
    participant C as Child / Container

    P->>D: await detect_runtime()
    D-->>P: Bare / Docker / Unsupported

    alt Bare (Linux/BSD/macOS/Windows)
        P->>S: spawn(policy, context)
        S->>C: exec --sandbox-worker
        S->>C: write ExecutionContext JSON to stdin
        S->>C: close stdin
        C->>C: read_context_from_stdin()
        C->>C: decrypt, execute, encrypt
        C-->>S: ExecutionResult JSON to stdout
        S->>S: reap_child_output(), store result
        P->>S: collect_result()
        S-->>P: (ExecutionResult, AttestationReceipt)
    else Docker
        P->>S: DockerSpawner::spawn(policy, context)
        S->>C: create_container(PAP_CONTEXT env var)
        S->>C: start_container
        Note over S,C: stdin opened but never written (BUG)
        C-->>S: stdout ExecutionResult JSON
        S->>S: poll_state() read_container_stdout()
        Note over S: container record not removed (BUG)
        P->>S: collect_result()
        S-->>P: (ExecutionResult, AttestationReceipt)
    end

Loading

Comments Outside Diff (6)

1. crates/pap-sandbox/src/platform/docker.rs, line 1342-1346 (link)

   Invalid Linux capability names in cap_drop

   SYS_FORK and SYS_CLONE are not valid Linux capability names — they are syscall names. Docker's --cap-drop (and HostConfig.cap_drop) operates on Linux capabilities (e.g. CAP_SYS_ADMIN, CAP_NET_ADMIN). Passing unknown names like "SYS_FORK" will likely cause container creation to fail with an API error. Restricting fork/clone at the syscall level requires a custom seccomp profile, not cap_drop.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: crates/pap-sandbox/src/platform/docker.rs
   Line: 1342-1346
   
   Comment:
   **Invalid Linux capability names in `cap_drop`**
   
   `SYS_FORK` and `SYS_CLONE` are not valid Linux capability names — they are syscall names. Docker's `--cap-drop` (and `HostConfig.cap_drop`) operates on Linux capabilities (e.g. `CAP_SYS_ADMIN`, `CAP_NET_ADMIN`). Passing unknown names like `"SYS_FORK"` will likely cause container creation to fail with an API error. Restricting fork/clone at the syscall level requires a custom seccomp profile, not `cap_drop`.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

2. crates/pap-sandbox/src/platform/docker.rs, line 1438-1457 (link)

   Container records and Docker containers not cleaned up on successful exit

   When a container exits and poll_state successfully parses the ExecutionResult, the result is stored in self.results but the corresponding ContainerRecord is never removed from self.containers, and remove_container is never called on the Docker daemon. Over the lifetime of a server, stopped containers accumulate in Docker and the containers HashMap grows unbounded. The terminate path does call remove_container, but the successful-exit path in poll_state does not.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: crates/pap-sandbox/src/platform/docker.rs
   Line: 1438-1457
   
   Comment:
   **Container records and Docker containers not cleaned up on successful exit**
   
   When a container exits and `poll_state` successfully parses the `ExecutionResult`, the result is stored in `self.results` but the corresponding `ContainerRecord` is never removed from `self.containers`, and `remove_container` is never called on the Docker daemon. Over the lifetime of a server, stopped containers accumulate in Docker and the `containers` HashMap grows unbounded. The `terminate` path does call `remove_container`, but the successful-exit path in `poll_state` does not.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

3. crates/pap-sandbox/src/platform/docker.rs, line 1328-1335 (link)

   Docker IPC mismatch: worker reads from stdin, Docker spawner only passes context via env var

   worker.rs::read_context_from_stdin() reads the ExecutionContext JSON from stdin and returns an error if stdin is empty. The Docker spawner passes the context exclusively via the PAP_CONTEXT env var and never writes anything to the container's stdin after start_container. Despite setting open_stdin: Some(true), the spawner never opens an attach-stream to write data. A worker binary using worker.rs would block indefinitely waiting for stdin content, or fail immediately with "empty stdin — no execution context received".

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: crates/pap-sandbox/src/platform/docker.rs
   Line: 1328-1335
   
   Comment:
   **Docker IPC mismatch: worker reads from stdin, Docker spawner only passes context via env var**
   
   `worker.rs::read_context_from_stdin()` reads the `ExecutionContext` JSON from stdin and returns an error if stdin is empty. The Docker spawner passes the context exclusively via the `PAP_CONTEXT` env var and never writes anything to the container's stdin after `start_container`. Despite setting `open_stdin: Some(true)`, the spawner never opens an attach-stream to write data. A worker binary using `worker.rs` would block indefinitely waiting for stdin content, or fail immediately with `"empty stdin — no execution context received"`.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

4. crates/pap-sandbox/src/platform/detection.rs, line 1073-1099 (link)

   Docker socket not checked on non-container hosts

   detect_runtime() only calls find_docker_socket() when is_in_container() returns true. On a bare-metal Linux host that has Docker installed but lacks seccomp support, the function falls through to RuntimeEnvironment::Unsupported even though a Docker socket is present and usable.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: crates/pap-sandbox/src/platform/detection.rs
   Line: 1073-1099
   
   Comment:
   **Docker socket not checked on non-container hosts**
   
   `detect_runtime()` only calls `find_docker_socket()` when `is_in_container()` returns `true`. On a bare-metal Linux host that has Docker installed but lacks seccomp support, the function falls through to `RuntimeEnvironment::Unsupported` even though a Docker socket is present and usable.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

5. Dockerfile, line 728-744 (link)

   Placeholder script uses env var, not stdin — incompatible with worker IPC protocol

   The fallback pap-agent bash script reads PAP_CONTEXT from the environment, but worker.rs::read_context_from_stdin() reads from stdin and fails on empty input. More critically, the script exits 0 without writing any ExecutionResult JSON to stdout, so the Docker spawner's read_container_stdout will parse an empty response and return ExecutionState::Failed.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: Dockerfile
   Line: 728-744
   
   Comment:
   **Placeholder script uses env var, not stdin — incompatible with worker IPC protocol**
   
   The fallback `pap-agent` bash script reads `PAP_CONTEXT` from the environment, but `worker.rs::read_context_from_stdin()` reads from stdin and fails on empty input. More critically, the script exits 0 without writing any `ExecutionResult` JSON to stdout, so the Docker spawner's `read_container_stdout` will parse an empty response and return `ExecutionState::Failed`.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

6. apps/papillon/src/lib.rs, line 767-777 (link)

   New Tokio runtime created inside Tauri setup — may conflict with existing runtime

   tokio::runtime::Runtime::new().expect(...) is called inside Tauri's setup closure. If this closure is ever called from within an existing async context, nesting runtimes panics on some platforms. A lighter-weight alternative is tokio::task::block_in_place or reusing whatever async runtime Tauri provides.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/papillon/src/lib.rs
   Line: 767-777
   
   Comment:
   **New Tokio runtime created inside Tauri setup — may conflict with existing runtime**
   
   `tokio::runtime::Runtime::new().expect(...)` is called inside Tauri's setup closure. If this closure is ever called from within an existing `async` context, nesting runtimes panics on some platforms. A lighter-weight alternative is `tokio::task::block_in_place` or reusing whatever async runtime Tauri provides.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

Fix the following 6 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 6
crates/pap-sandbox/src/platform/docker.rs:1342-1346
**Invalid Linux capability names in `cap_drop`**

`SYS_FORK` and `SYS_CLONE` are not valid Linux capability names — they are syscall names. Docker's `--cap-drop` (and `HostConfig.cap_drop`) operates on Linux capabilities (e.g. `CAP_SYS_ADMIN`, `CAP_NET_ADMIN`). Passing unknown names like `"SYS_FORK"` will likely cause container creation to fail with an API error. Restricting fork/clone at the syscall level requires a custom seccomp profile, not `cap_drop`.

### Issue 2 of 6
crates/pap-sandbox/src/platform/docker.rs:1438-1457
**Container records and Docker containers not cleaned up on successful exit**

When a container exits and `poll_state` successfully parses the `ExecutionResult`, the result is stored in `self.results` but the corresponding `ContainerRecord` is never removed from `self.containers`, and `remove_container` is never called on the Docker daemon. Over the lifetime of a server, stopped containers accumulate in Docker and the `containers` HashMap grows unbounded. The `terminate` path does call `remove_container`, but the successful-exit path in `poll_state` does not.

### Issue 3 of 6
crates/pap-sandbox/src/platform/docker.rs:1328-1335
**Docker IPC mismatch: worker reads from stdin, Docker spawner only passes context via env var**

`worker.rs::read_context_from_stdin()` reads the `ExecutionContext` JSON from stdin and returns an error if stdin is empty. The Docker spawner passes the context exclusively via the `PAP_CONTEXT` env var and never writes anything to the container's stdin after `start_container`. Despite setting `open_stdin: Some(true)`, the spawner never opens an attach-stream to write data. A worker binary using `worker.rs` would block indefinitely waiting for stdin content, or fail immediately with `"empty stdin — no execution context received"`.

### Issue 4 of 6
crates/pap-sandbox/src/platform/detection.rs:1073-1099
**Docker socket not checked on non-container hosts**

`detect_runtime()` only calls `find_docker_socket()` when `is_in_container()` returns `true`. On a bare-metal Linux host that has Docker installed but lacks seccomp support, the function falls through to `RuntimeEnvironment::Unsupported` even though a Docker socket is present and usable.

### Issue 5 of 6
Dockerfile:728-744
**Placeholder script uses env var, not stdin — incompatible with worker IPC protocol**

The fallback `pap-agent` bash script reads `PAP_CONTEXT` from the environment, but `worker.rs::read_context_from_stdin()` reads from stdin and fails on empty input. More critically, the script exits 0 without writing any `ExecutionResult` JSON to stdout, so the Docker spawner's `read_container_stdout` will parse an empty response and return `ExecutionState::Failed`.

### Issue 6 of 6
apps/papillon/src/lib.rs:767-777
**New Tokio runtime created inside Tauri setup — may conflict with existing runtime**

`tokio::runtime::Runtime::new().expect(...)` is called inside Tauri's setup closure. If this closure is ever called from within an existing `async` context, nesting runtimes panics on some platforms. A lighter-weight alternative is `tokio::task::block_in_place` or reusing whatever async runtime Tauri provides.

_{Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile}

[toadkicker]

Greptile Review — All 6 Findings Addressed

Fixed in commit 98eb3cc. Summary of changes:

P1 — Invalid cap_drop names (docker.rs)
Replaced SYS_FORK/SYS_CLONE (syscall names, not Linux capabilities) with cap_drop: ALL + selective cap_add: NET_RAW when network is allowed. This is Docker's best-practice for sandboxed containers.

P1 — Container records not cleaned up (docker.rs)
poll_state now calls remove_container on the Docker daemon and removes the ContainerRecord from the tracking HashMap after reading output — both success and failure paths.

P1 — Docker IPC mismatch (worker.rs, docker.rs)
Worker now checks PAP_CONTEXT env var first (Docker path), falls back to stdin (native spawner path). Removed unused attach_stdin/open_stdin from Docker container config. Both native and Docker spawners now have a clean IPC contract.

P2 — Docker socket not checked on non-container hosts (detection.rs)
detect_runtime() now checks for Docker socket as a fallback when no native OS capabilities are detected — covers the bare-metal-host-with-Docker-but-no-seccomp case.

P2 — Dockerfile placeholder incompatible with worker IPC (Dockerfile)
Fallback script now exits non-zero with stderr message instead of silently succeeding with no ExecutionResult output. Parent sees ExecutionState::Failed instead of empty/corrupted result.

P2 — Nested Tokio runtime in Tauri setup (papillon/lib.rs)
Added clarifying comment — Tauri 2's setup closure is sync (main thread, no existing async context), so Runtime::new() is safe here. Not a runtime nesting issue in practice.

Re: bollard version — We're on 0.14, latest is 0.20.2. Upgrade deferred to a separate PR since it's a major version jump with potential API changes unrelated to this sandbox work.