# Yolobox

> Use when the agent is running inside yolobox and needs to orient itself to the current sandbox, trust model, runtime/config, mounts, network mode, readonly/output paths, Docker access, forwarded env keys, or other environment constraints and freedoms. Also use when the user explicitly invokes /yolobox.

- Skill: `finbarr/yolobox` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add finbarr/yolobox`
- Raw SKILL.md: https://api.skillmd.com/api/skills/finbarr/yolobox/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: MIT
- Author: finbarr (https://skillmd.com/u/finbarr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/finbarr/yolobox

---


# Yolobox

Use this skill only for questions about the current yolobox environment from inside the container.

1. Run the bundled helper first: `/opt/yolobox/skills/yolobox/scripts/describe-yolobox-context.sh`. Do not look for `scripts/describe-yolobox-context.sh` in the project checkout.
2. Treat this as agent orientation, not a user-facing product explanation. The goal is to help yourself understand how boldly or carefully to operate inside this sandbox.
3. Assume the user is telling you that this is a trusted yolobox environment and you may work normally within its boundaries: use `sudo` if needed, install tools or packages if they help, and rely on the YOLO wrappers unless the manifest or user says otherwise.
4. Call out the important operating assumptions for the current session:
   - you are inside a containerized sandbox, not on the host
   - `127.0.0.1` refers to this container, not the user's host
   - the project is mounted in unless `Automatic project mount` is false; host files outside the exposed mounts are out of reach by default
   - write access, output path, network access, Docker access, Claude host-config/auth mode, any explicitly configured npm package release-age setting, env passthrough, host clipboard/open bridges, and forwarded env keys depend on the current manifest and environment
   - if fork mode is active, this project is a copied folder mounted at the original source path and `COMPOSE_PROJECT_NAME` is namespaced for the fork
   - if `Container platform` is shown, the box is running a non-default architecture, so it may be emulated and slower, prebuilt binaries must match that architecture, and its persistent volumes are separate from the native ones
5. Prefer concrete facts from `YOLOBOX_CONTEXT_FILE` over generic assumptions. Mention whether the automatic project mount is active, the current project path when present, workdir, runtime, architecture and container platform when shown, container name when present, readonly/output behavior, network mode, whether a copied Claude config keeps authentication container-local, any npm package release-age setting shown by the helper, env passthrough mode, Docker socket access, SSH agent access, GitHub token availability for HTTPS Git auth, host clipboard/open bridge access, fork/Compose namespace if present, and any relevant env keys or customization settings. In the script output, `Readonly project mode` is the yolobox launch mode and `Project writable now` is the current filesystem write check; when the automatic project mount is disabled, do not assume the original checkout path exists inside the container.
6. If the script had to fall back to inference instead of the manifest, say so explicitly.
7. If the user needs a specific field or the raw manifest, run `/opt/yolobox/skills/yolobox/scripts/describe-yolobox-context.sh --json` or query `$YOLOBOX_CONTEXT_FILE` directly with `jq`.
8. Do not claim you are inside yolobox unless `YOLOBOX=1` or the manifest confirms it.
9. Keep the answer concise and operational. Do not waste space re-explaining yolobox unless that explanation is directly useful for how you should behave.