Sandbox agent process execution behind one constrained Linux boundary

[RaresKeY]

Prerequisites

• I searched open issues and pull requests. Add Codex-style sandboxed agent execution for safer use with untrusted content #4754 owns the broad safe-agent request and Make agent execution authority deterministic across untrusted context and privileged tools #5815 owns this four-slice stack, but no separate issue owns the exact process-boundary acceptance criteria implemented by candidate PR fix(agent): sandbox process execution #5818.
• I searched discussions. Discussion Prompt injection security #335 discusses sandboxing generally but does not define this process-routing and positive-mount contract.
• This is a concrete, actionable child slice of Make agent execution authority deterministic across untrusted context and privileged tools #5815.

Area

Auth / Security

Problem or Motivation

Agent-requested Bash, Python, tmux, and detached jobs can otherwise inherit the application process environment, host networking, and broad filesystem access. A prompt-level tool gate reduces which calls reach execution, but it does not confine a permitted or misclassified process once it starts.

This is the second focused acceptance-criteria slice of #5815. It should provide one deterministic Linux process boundary without taking ownership of the higher-level thread mode, exact approval, private-read, or sensitive-egress policies in later slices.

Proposed Solution

• Route foreground Bash and Python, tmux sessions, and detached/background process jobs through one shared Linux sandbox construction path.
• Build the sandbox from positive filesystem mounts, a cleared environment, private temporary and home directories, bounded process resources, no ambient capabilities, and network isolation by default.
• Permit writes only within the selected workspace while protecting repository metadata, Odysseus data stores, configured databases, credentials, host configuration, system roots, and home-like roots.
• Fail closed when the sandbox cannot be established, the platform is unsupported for Sandbox mode, or the selected workspace cannot be safely constrained.
• Preserve an explicit server-owned higher-level choice for any future Full Access path; individual tools or model-controlled input must not widen the sandbox implicitly.
• Add argv, path-canonicalization, foreground/background routing, positive execution, negative isolation, and shipped-container runtime validation.

Alternatives Considered

Earlier optional container sandboxes were closed and either defaulted off or fell back to host execution. Maintaining separate wrappers for each subprocess path risks policy drift. Process isolation also cannot replace the capability, approval, or provenance layers owned by the other #5815 children.

Prior Art / Related Issues

Parent tracker: #5815

Candidate implementation: the focused child chain below; #5818 remains source coordination context.

Related: #4754, #3709, #6021, and Discussion #335. Earlier attempts include #751 and #3695.

Child Issues

• #6114 — trusted seccomp launcher and deterministic generated policies.
• #6115 — trusted sandbox HTTP(S) egress broker and bridge.
• #6116 — route agent Bash, Python, tmux, and background jobs through the common process sandbox core.
• #6117 — make the sandbox start on supported Docker/Compose hosts with AppArmor and boot diagnostics.
• #6099 — make workspace selection validate the current input, provide a managed default and safe folder creation, persist per-user state, and expose the process-sandbox policy accurately. Candidate implementation: #6100.

Candidate Implementation Chain

• Issue #6114 → PR #6119 — independently reviewable seccomp substrate.
• Issue #6115 → PR #6118 — independently reviewable egress substrate.
• Issue #6116 → PR #6120 — consumes both PR #6119 and PR #6118.
• Issue #6117 → PR #6121 — integrates PR #6119, PR #6118, and PR #6120 for shipped container posture.

Are you willing to implement this?

Yes — I can open a PR