kubernetes-sigs/agent-sandbox

I was investigating what the minimum version of Kubernetes that Agent Sandbox can run on today, and did not find an obvious answer in the repo. There was also not a known answer from the team in Slack. I will run the E2E test suite on older clusters to find which version tests fail on, and then submit a PR with documentation updates reporting the last working version as the minimum K8s version for Agent Sandbox.

Problem The published docs don't say which status conditions a Sandbox reports, what reasons they carry, or which one to check for a given question. The API reference only describes status.conditions as "the status conditions array". Today the only full list is in the Go doc comments in api/v1beta1/sandbox_types.go, and those have drifted from the controller: The Suspended comment names the deprecated PodNotTerminated reason. The ReconcilerError reason exists only as a string literal in the controller, not as a constant. Proposal Add a conditions page to the docs site with two parts. 1. How to use the conditions (hand-written). Map common questions to the condition to check and a kubectl command, for example: Question Check Command Is the sandbox ready to use? Ready=True kubectl wait sandbox/<name> --for=condition=Ready --timeout=2m Why isn't it ready? Ready reason and message, plus PodScheduled (e.g. Unschedulable) kubectl get sandbox <name> -o jsonpath='{range .status.cond

The docs site has a set of UI defects that are easier to track together than one at a time. Everything below was measured on the deployed site (https://agent-sandbox.sigs.k8s.io, Hugo 0.163.3, main, 2026-09-15). They are independent, so they can be picked off one at a time. Content unreachable The navbar never collapses. (#1659) At a 390px viewport, .navbar-collapse computes to display:flex at 983px wide and .navbar-toggler to display:none, so the document is 1118px wide and six of eight nav links are off-screen with no way to reach them. Cause: site/layouts/partials/navbar.html#L6-L9 is a fork of the Bootstrap 4 Docsy navbar (collapse navbar-collapse plus a data-toggle button), while current Docsy ships .td-navbar .navbar-collapse { display: flex !important } and .td-navbar .navbar-toggler { display: none } outside any media query. The fork gets neither behaviour. Fix: drop the custom partial, or move it to Docsy's current markup (td-navbar-nav-scroll, no toggler). Tables spill

What would you like to be added? A small, reproducible RLlib training and evaluation example that reuses the existing SandboxEnv integration. The project already provides: Ray-based sandboxed code execution examples (#742, #868). A Gymnasium-compatible SandboxEnv and a Hugging Face TRL PPO training notebook (#1350). An official Ray/KubeRay integration guide, including sandbox suspend/resume. Building on these existing integrations, an end-to-end example connecting SandboxEnv to RLlib for actual training and evaluation is still missing. Why is this needed? The roadmap lists Ray/RLlib integration as in progress. A runnable RLlib example would help users bridge the gap between the existing Gymnasium interface and a distributed training workflow. In particular, SandboxEnv exposes text-based action and observation spaces. Users still need to adapt these to spaces supported by their chosen RLlib algorithm, construct SDK clients within remote environment processes, and manage independent sa

What would you like to be added? Add a streaming download API to the supported SDKs so callers can copy a file into a destination without materializing the complete response in memory. The existing APIs should remain available and backward compatible: Python: Filesystem.read() and AsyncFilesystem.read() should continue to return bytes. Go: Files.Read() should continue to return []byte. A new API could write incrementally to a caller-provided sink, for example a Python binary file-like object / async sink and a Go io.Writer. The exact public API names can be decided during implementation. Why is this needed? The current download implementations buffer the whole response: Python sync read() accesses response.content. Python async read() also accesses response.content. Go Files.Read() uses io.ReadAll. This makes client memory usage proportional to file size even though both HTTP runtimes can deliver response bodies incrementally. It is especially limiting for agent workloads that need