kubernetes-sigs/agent-sandbox

What happened? Tool calls in the sandboxed-tools example run without a dedicated execution timeout (TODO markers exist in main.go and run_command.go). A long-running or hung command (e.g., sleep 99999) blocks the agent loop indefinitely with no way to recover. Expected: a bounded timeout causes the tool call to fail fast and return a clear, deterministic error message. How can we reproduce it (as minimally and precisely as possible)? Run the sandboxed-tools example agent. Trigger a tool call that executes a never-ending command, e.g.: run_command("sleep 99999") Observe: the agent loop hangs indefinitely and never returns. Version latest Anything else we need to know? Proposed change: Add a configurable execution timeout (flag and/or env var) for each tool call. Wrap tool execution context with context.WithTimeout(...). Return a clear error message when timeout is exceeded. Update examples/sandboxed-tools/README.md with the new option and its default value.

What would you like to be added? Add sandboxd runtime support to the Python AsyncSandboxClient, keeping it functionally aligned with the synchronous SandboxClient. The synchronous client now supports SandboxdPodTunnelConnectionConfig, but the async connector explicitly rejects it: if isinstance(connection_config, SandboxdPodTunnelConnectionConfig): raise NotImplementedError( "The async client does not support the sandboxd runtime ..." ) This leaves async applications unable to use the project's portable runtime backend. Why is this needed? The Python SDK treats sync/async parity as an important compatibility requirement, and async applications (FastAPI services, async agent orchestrators, notebook services) should not need to switch to blocking SDK calls to use sandboxd. The gap was introduced with the initial SDK migration in #1347. I could not find an existing issue tracking async sandboxd support. Proposed scope Support SandboxdPodTunnelConnectionConfig in AsyncSand

What would you like to be added? When managing multiple SandboxWarmPools backed by different SandboxTemplates, kubectl get sandboxwarmpool currently shows only Ready, Desired, and Age. There is no way to see which template backs which pool without inspecting each resource individually. Adding sandboxTemplateRef.name as a priority=1 printer column (visible with -o wide) would make the pool-to-template mapping immediately visible: $ kubectl get sandboxwarmpool -o wide NAME READY DESIRED AGE TEMPLATE python-warmpool 3 3 10m python-sandbox-template node-warmpool 5 5 10m node-sandbox-template PR #1002 previously proposed this (among other columns for all four CRDs) and received lgtm but was self-closed due to inactivity, not a design objection. PR #1053 later landed just the Desired column from that set. This issue is scoped to the single remaining Template column on SandboxWarmPool. The implementation is a one-line kubebuild

What would you like to be added Filesystem.write / AsyncFilesystem.write (k8s-agent-sandbox 0.5.4) accept content: bytes | str, so a caller must materialize the entire payload in memory before uploading. For large workspace files (datasets, archives, model outputs) that is a transient memory spike on the client, and callers integrating the sandbox behind streaming-oriented interfaces (e.g. the OpenAI Agents SDK's sandbox session contract, which hands backends an io.IOBase precisely so they can stream) end up buffering or imposing artificial size caps. The wall is thin, because both ends already stream: the transport (httpx / requests) natively streams file-like objects in multipart payloads — files={"file": (path, fileobj)} works today; the runtime server receives the upload through FastAPI's UploadFile, which spools to disk rather than holding memory. Only the client signature forces the buffering. Proposed change Widen the accepted type and pass file-like objects through: async d

What would you like to be added? A get_sandbox_status tool for the Agent Sandbox MCP server (clients/integrations/mcp-server). The tool takes a sandbox claim name + namespace and returns the sandbox's readiness, e.g.: json { "status": "SandboxReady", "ready": true, "message": "..." } status is one of SandboxReady / SandboxNotReady / SandboxNotFound. It is a thin wrapper over the existing Python SDK method AsyncSandbox.status(), which already reads the Sandbox's Kubernetes Ready condition. No SDK or runtime changes are required. Like the other tools, it routes through the existing get_sandbox() helper, so it inherits the per-session ownership check unchanged and fails closed. Why is this needed? The MCP server exposes create_sandbox, delete_sandbox, execute_command, upload_file, download_file, etc. but has no way to check whether a sandbox is Ready. An agent driving the server currently has to blindly call execute_command and interpret a connection error, instead of confirming readines