troubleshoot-sandbox — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited troubleshoot-sandbox (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Troubleshoot sandbox $ARGUMENTS using the opensandbox diagnostics.
There are two ways to interact with the diagnostics API: CLI (if opensandbox CLI is installed) or HTTP (curl against the server directly). Use whichever is available. The HTTP approach works regardless of how the sandbox was created (SDK, API, CLI).
CLI:
opensandbox sandbox get <sandbox-id>HTTP:
curl http://<server-domain>/v1/sandboxes/<sandbox-id>If the server requires authentication, add -H "OPEN-SANDBOX-API-KEY: <your-key>" to all curl commands.
Check the sandbox status (Running, Pending, Paused, Failed, etc.). If the sandbox is not found, it may have been deleted or expired.
CLI:
opensandbox devops summary <sandbox-id>HTTP:
curl http://<server-domain>/v1/sandboxes/<sandbox-id>/diagnostics/summaryThis returns a combined plain-text view of:
Read the output carefully and look for common failure patterns listed below.
If the summary is not enough, use individual endpoints for more detail:
CLI:
opensandbox devops logs <sandbox-id> --tail 500
opensandbox devops logs <sandbox-id> --since 30m
opensandbox devops inspect <sandbox-id>
opensandbox devops events <sandbox-id> --limit 100HTTP:
# Get more log lines
curl "http://<server-domain>/v1/sandboxes/<sandbox-id>/diagnostics/logs?tail=500"
# Get logs from recent time window
curl "http://<server-domain>/v1/sandboxes/<sandbox-id>/diagnostics/logs?since=30m"
# Detailed container/pod inspection
curl "http://<server-domain>/v1/sandboxes/<sandbox-id>/diagnostics/inspect"
# More events
curl "http://<server-domain>/v1/sandboxes/<sandbox-id>/diagnostics/events?limit=100"| Symptom | What to check | Likely cause |
|---|---|---|
| Status=Pending, no IP | inspect - look for Waiting containers | Image pull failure, insufficient resources, node scheduling |
| OOMKilled=true | inspect - check memory limits | Container exceeded memory limit, increase memory resource |
| Exit Code 137 | events + logs | OOM kill or external SIGKILL |
| Exit Code 1 | logs - check application output | Application error, check entrypoint and env vars |
| Exit Code 126/127 | logs | Entrypoint command not found or not executable |
| Connection refused to sandbox | inspect - check ports and network | Service not started inside sandbox, wrong port, network policy blocking |
| Sandbox stuck in Running but unresponsive | logs (tail=200) | Application hung, check for deadlocks or resource exhaustion |
| execd health check failing | logs - look for execd errors | execd daemon crashed or port conflict |
| ImagePullBackOff (K8s) | events | Wrong image name, missing registry credentials |
| CrashLoopBackOff (K8s) | events + logs | Application keeps crashing, check exit code and logs |
Based on the diagnosis, suggest one of:
memory=4Gi)All diagnostics endpoints return text/plain and are available at:
| Endpoint | Query Params | Description |
|---|---|---|
GET /v1/sandboxes/{id}/diagnostics/summary | tail (default 50), event_limit (default 20) | Combined inspect + events + logs |
GET /v1/sandboxes/{id}/diagnostics/logs | tail (default 100), since (e.g. 10m, 1h) | Container/pod logs |
GET /v1/sandboxes/{id}/diagnostics/inspect | - | Container/pod detailed state |
GET /v1/sandboxes/{id}/diagnostics/events | limit (default 50) | Container/pod events |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.