recipe-maintainers/recipe-maintainer
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
460eba090ba6765b05a929d32d16ca984cf66e5a
recipe-maintainer/.claude/commands/setup-sandbox.md
autonomic-bot f283a371bb recipe-maintainer: public snapshot (secrets + deployment plans removed, single commit) 
Sanitized single-commit public mirror of recipe-maintainer.
- Removed test-ssh/.testenv (live creds); added test-ssh/.testenv.example placeholders.
- Removed plans/ and planned-updates/ (deployment-planning docs) so no client/
  deployment domains appear in the public repo.
- All other secret stores were already gitignored.
- docs.coopcloud.tech retained as a submodule (public upstream).
2026-06-16 20:18:24 +00:00

2.5 KiB
Raw Blame History

description, allowed-tools
description allowed-tools
Guide for setting up a sandboxed environment to run Claude Code with recipe-maintainer
Read
Glob
Grep

Setup Sandbox

Explain to the user how to set up a sandboxed environment for running Claude Code with access to recipe-maintainer.

What to explain

Claude Code needs shell access to run commands, edit files, and install packages. Running it inside a sandbox (like a Docker container) keeps it isolated from your host system while still giving it the tools it needs.

For recipe-maintainer, the sandbox needs:

  • Its own ~/.abra directory — so it can manage Co-op Cloud apps and servers without touching your host abra config
  • Access to the recipe-maintainer checkout — mounted as a volume
  • CLI tools: abra, git, gh, ripgrep, fd, and anything else your recipes need (Rust, Hugo, Terraform, etc.)
  • Network access — to reach Co-op Cloud servers (via Tailscale or direct SSH)
  • Persistent home directory — so Claude's auth, settings, and conversation history survive across runs

Reference implementation

Point the user to sandbox/ in this repo. Read sandbox/README.md and summarise the key points:

  • sandbox/ contains a working Docker-based sandbox with all the tools recipe-maintainer uses
  • claude.py is the launcher — it mounts the current directory, maps your UID/GID, and hides sensitive files
  • docker-compose.yml defines named volumes for persistence (claude_userhome, claude_target, tailscale_state)
  • entrypoint.sh creates a non-root user matching the host UID/GID
  • The Dockerfile includes all the tools needed for recipe work (abra, Caddy, Tailscale, Rust, Hugo, Terraform, Playwright, etc.)

Tell the user they can either:

  1. Use sandbox/ directly — ./build.sh then set up an alias to claude.py
  2. Build their own — use sandbox/ as a reference for what tools and configuration are needed

Key details to mention

  • The .abra directory is mounted per-workspace via -v ${workspace}/.container-abra:/home/claude/.abra so each project can have its own abra config
  • Sensitive files (.env, secret.json, etc.) are automatically hidden from the container via /dev/null mounts
  • The container runs with --dangerously-skip-permissions by default since the sandbox itself is the security boundary
  • Auth persists in the claude_userhome Docker volume — run claude login once and it sticks

Read sandbox/README.md for full details and present a clear summary to the user.