菜单
Executes a command on a playground VM via SSH. Use when you need to run commands on a playground for testing, debugging, or verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Debugs an existing challenge by starting it, inspecting tasks, troubleshooting over SSH, fixing source files, and restarting. Use when a challenge's tasks are failing or hanging.
Gets detailed status and output of a specific examiner task on a playground. Use to debug why a task is failing.
Lists all examiner tasks (init and regular) for a playground. Use to check the status of challenge/tutorial tasks.
Applies a scripted solution to a running challenge (single- or multi-VM) and verifies every non-helper task completes. Use to validate a .solution.sh / .solution-NN.sh end-to-end.
Starts a challenge playground session. Use when you need to launch a challenge for testing or solving.
Stops the current solution attempt for a challenge. Use when you need to stop a running challenge.
| name | run-playground-command |
| description | Executes a command on a playground VM via SSH. Use when you need to run commands on a playground for testing, debugging, or verification. |
| argument-hint | <playground-id> [command] |
Run a command on playground $0.
If a specific command is provided, run it directly:
labctl ssh $0 -- <command>
For example:
labctl ssh $0 -- curl 127.0.0.1:9000
labctl ssh $0 -- cat /etc/os-release
labctl ssh $0 -- systemctl status nginx
To target a specific machine in a multi-machine playground:
labctl ssh $0 --machine <machine-name> -- <command>
If no specific command is given or multiple commands need to be run interactively, start an interactive SSH session:
labctl ssh $0
-- are executed on the remote VM and their output is returned.top, vim), use an interactive session instead.labctl ssh borrows a tunnel slot from a small per-account pool. Misusing it
bricks all SSH for the session with a cryptic error:
labctl: Couldn't start SSH session: couldn't start tunnel: client.StartTunnel(): retry after 2562047h47m16s.
That 2562047h... is an int64 overflow meaning "no slots free" - not a real
wait time. It is almost always caused by orphaned labctl ssh processes left
behind by backgrounded retry loops: when the parent shell is killed, the labctl ssh child keeps running and holds its slot.
labctl ssh in a backgrounded for ... sleep retry loop, and
never launch several labctl ssh calls concurrently. Run ssh calls in the
foreground, one at a time.labctl playground tasks <id> - it reads via
the API and needs no tunnel (see the list-playground-tasks skill). Reserve
SSH for inspecting a specific task's stdout/stderr or running diagnostics.pkill -9 -f 'labctl ssh', then retry a single
foreground call. If it persists, labctl challenge stop + start (or restart the
playground) to release server-side slots. Auth and API calls (content push,
playground tasks) keep working throughout - only the tunnel is affected.