Track a future SandboxOperator for sandboxed command/job execution

[zozo123]

Scope

This issue tracks a future SandboxOperator (and a @task.sandbox decorator) — an Airflow task that runs one author-defined command or job in an isolated, ephemeral sandbox. It complements the sandboxed-execution surfaces already in flight and is opened to keep the roadmap explicit and the boundaries clear; no implementation is proposed here yet.

Where it sits

These are separate execution boundaries, not one API and not a monotonic security ranking:

Surface	What runs in the sandbox	Tracked by
Restricted code orchestration	Monty-compatible glue code	#68407 (merged)
Sandboxed code execution as a tool	model-generated full Python; the agent stays outside	#68847
Sandboxed command/job execution	one author-defined command or job	this issue
Sandboxed TaskInstance execution	the complete Task SDK ExecuteTask workload	#68845

What a SandboxOperator would add over the toolset (#68847)

The toolset gives an agent a run_python_in_sandbox tool inside a single task. A SandboxOperator would instead be the task and own a real task lifecycle:

• author-declared command / image / inputs;
• file and artifact upload and download;
• cancellation and, ideally, deferrable/resumable execution that frees the worker slot while the sandbox runs;
• streamed and reconnectable logs.

It would reuse the same sandbox code-execution adapters where practical, but its contract is a task lifecycle, not a code-execution adapter — and it is explicitly not an executor (that whole-task surface is tracked separately in #68845).

Status

Future work; no implementation planned yet. Opened so the roadmap is fully issue-backed and the scope boundaries between the tool, operator, and executor layers stay explicit.

---

Drafted-by: Claude Code (Opus 4.8) (no human review before posting)