Route agent Bash, Python, tmux, and background jobs through the common sandbox core

[RaresKeY]

Prerequisites

• I searched open issues and pull requests first. #6091 is the process-sandbox tracker and #5815 is the broader authority tracker; no separate open item owns this common process-routing contract.
• I searched discussions and did not find this concrete process-routing proposal already being debated.
• This is a concrete, actionable child slice of the existing sandbox work.

Area

Auth / Security

Problem or Motivation

Foreground commands, interactive tmux sessions, and detached/background jobs can drift into different execution paths unless they share one server-owned process-sandbox construction path. The cumulative #5818 proposal contains the routing, confinement, cleanup, and capability behavior needed here, but those semantics should be reviewed separately from the low-level security substrate and host deployment work.

Proposed Solution

Scope

• Route foreground Bash and Python, tmux sessions, and detached/background process jobs through one common process-sandbox core.
• Construct the sandbox from positive filesystem mounts, a cleared environment, private temporary and home directories, bounded process resources, no ambient capabilities, and an explicit network profile.
• Allow writes only within the selected workspace while protecting repository metadata, Odysseus data stores, configured databases, credentials, host configuration, system roots, and home-like roots.
• Preserve the server-owned internal capability/profile contract needed by subprocesses and detached jobs, while keeping user-facing authority selection in its own follow-up.
• Rotate or invalidate long-lived tmux/background execution state when the effective policy changes and clean up artifacts after failed launches.
• Fail closed when the sandbox cannot be established, the platform is unsupported for Sandbox mode, or the workspace cannot be safely constrained.
• Update the threat-model documentation to match the implemented process boundary and its residual limits.

Non-goals

• This issue does not implement the seccomp launcher or generated policy substrate; that is a separate child of #6091.
• This issue does not implement the HTTP(S) egress broker or bridge; that is a separate child of #6091.
• This issue does not own Docker/Compose/AppArmor/boot integration; that is the deployment child.
• This issue does not add thread authority modes or exact one-use approvals; see #6092.
• Scheduled action execution remains outside this slice and is tracked separately in #6021.
• Workspace selection and persistence remain the separate #6099 follow-up.

Validation contract

• Test foreground Bash and Python routing, tmux session rotation, detached/background launch and cleanup, and failure handling.
• Test positive execution inside the selected workspace and negative access to protected paths, repository metadata, databases, credentials, host configuration, and home-like roots.
• Test environment clearing, resource bounds, network-profile propagation, SQLite protection, canonical path handling, and unsupported-platform fail-closed behavior.
• Run positive and negative Bubblewrap-backed runtime checks where supported, and identify unrun host-level checks owned by the deployment child.

Alternatives Considered

Maintaining separate wrappers for Bash, Python, tmux, and background jobs invites policy drift. Prompt-level restrictions do not constrain a process after it starts. Disabling all process tools would avoid the routing problem but would remove the safe sandbox capability this tracker is intended to provide.

Prior Art / Related Issues

Parent tracker: #6091

Broader tracker: #5815

Workspace follow-up: #6099

Scheduled-actions follow-up: #6021

Source coordination proposal: #5818

Candidate implementation and dependencies

The candidate implementation is PR #6120, which consumes the independently reviewable seccomp substrate PR #6119 and egress substrate PR #6118. It requires PR #6121 for shipped Docker/runtime integration; the standalone image/Trivy check remains blocked against dev until #6119 lands, and real Ubuntu Docker/Compose/AppArmor host validation remains required.

Are you willing to implement this?

Yes — I can open a PR

[RaresKeY]

Candidate implementation: PR #6120, opened as a draft against dev.

Dependency links:

• Seccomp substrate: #6119 — open draft PR; not merged.
• Egress broker/bridge: #6118 — open draft PR; not merged.
• Container-host integration: #6117 — open issue; not merged.
• Process-sandbox parent: #6091.
• Broader authority tracker: #5815.

PR #6120 is limited to the common application process boundary: fail-closed Sandbox-by-default execution for Bash/Python, tmux, and detached jobs, SQLite/path protection, network-profile propagation, the internal capability/profile contract, threat-model alignment, and focused regression tests. User-facing authority selection/API/UI remain with #6092 and #5819; the low-level security substrate and host integration remain in the linked dependencies above.