Loading ToolBench
Disposable sandbox computers for ChatGPT, running on your hardware.
chat2sbx demonstrates solid tool design with complete schemas, clear descriptions, and proper tool annotations. All 9 tools have input schemas with type definitions and descriptions. Tool names follow verb_noun conventions (sandbox_create, sandbox_list, bash). Descriptions are substantive (100-300 chars typical), explaining what each tool does and when to use it. Output schemas are documented for bash operations. However, some parameter descriptions lack actionable constraints (e.g., memory pattern is documented but not explained in description text), and error handling guidance is minimal. Tool composition is clean, each tool has a single responsibility. The bash_* tools properly chain via session_id. No secrets exposed as parameters.
Run unrestricted Bash inside the selected sandbox and return an execution session. Poll it with bash_poll while status is running or has_more_output is true, or terminate it with bash_stop. There is no execution timeout unless timeout_ms is explicitly provided. The command cannot access the host shell or host Docker daemon.
Wait for new output, process exit, or yield expiry, then return only new combined stdout/stderr and current status. Poll again while status is running or has_more_output is true.
Stop a running Bash session with SIGTERM, followed by SIGKILL after 1.5 seconds if it has not exited.
Create an isolated Docker Sandbox with a new managed workspace, or reuse the active sandbox for an existing managed workspace. A created or reused sandbox includes the current global sandbox instructions when AGENTS.md exists in the chat2sbx data directory.
Permanently remove one sandbox microVM. Its managed workspace files are retained for 30 days.
Parameter descriptions lack actionable constraints. 'memory' parameter has a regex pattern (^[1-9][0-9]*(m|g)$) but the description does not explain the format, LLMs cannot read JSON Schema patterns and will guess at valid values.
Error handling lacks recovery guidance. Tools return errors but do not tell the LLM what to do next (e.g., 'Sandbox not found. Call sandbox_list() to see available sandboxes.').
sandbox_expose description does not explain the security implications of port exposure or the default host binding (127.0.0.1). LLMs may misunderstand whether the port is accessible from outside the host.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2025-06-18+ | v2 |
Publish one TCP/IPv4 port mapping from a running sandbox. sandbox_port is the port inside the sandbox. host is the host IPv4 bind address and defaults to 127.0.0.1. host_port is the host-side port and is allocated automatically when omitted. The service inside the sandbox must listen on 0.0.0.0. The mapping has no separate authentication or expiration and disappears with the sandbox. Traffic through it does not renew sandbox activity.
Get the current state, workspace, expiration times, and current global sandbox instructions for one sandbox.
List all non-destroyed sandboxes owned by the current chat2sbx principal, including creating, running, destroying, and failed records. Running IDs can be reused from other conversations; failed sandboxes must be destroyed.
List all known managed workspaces for the current principal, including active, retained, and archived records.
bash tool lacks explicit timeout behavior documentation. Description says 'no execution timeout unless timeout_ms is explicitly provided' but does not explain what happens if a process hangs, does it block indefinitely, or is there a server-side hard limit?
No confirmation or dry-run pattern for destructive operations (sandbox_destroy, bash_stop). Agents can irreversibly delete sandboxes without a safety gate.