DE

dev-desktop-sandbox

Isolates development environments by creating temporary directories and managing port allocation for Vite and Electron debugging.

Install

mkdir -p .claude/skills/dev-desktop-sandbox && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8071" && unzip -o skill.zip -d .claude/skills/dev-desktop-sandbox && rm skill.zip

Installs to .claude/skills/dev-desktop-sandbox

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Run isolated mux desktop (Electron) instances (temp MUX_ROOT + free ports)
74 charsno explicit “when” trigger
Advanced

Key capabilities

  • Create temporary MUX_ROOT
  • Allocate free ports for Vite/Electron
  • Isolate environment variables
  • Launch parallel Electron instances

How it works

The skill creates a fresh temporary directory and manages port allocation to allow multiple Electron instances to run side-by-side.

Inputs & outputs

You give it
Sandbox launch command
You get back
Isolated Electron instance

When to use dev-desktop-sandbox

  • Running multiple Electron dev instances in parallel
  • Testing different git worktrees in isolated sandbox environments
  • Avoiding provider credential conflicts during development

About this skill

Desktop (Electron) sandbox instances

make dev + make start (Electron) uses MUX_ROOT for persisted state (config, sessions, worktrees, etc.). Running multiple Electron instances against the same mux root is noisy and risky during development.

This skill documents the repo workflow for starting multiple desktop dev instances in parallel (including from different git worktrees) by giving each instance its own temporary MUX_ROOT.

Quick start

make dev-desktop-sandbox

What it does

  • Creates a fresh temporary MUX_ROOT directory
  • Copies these files into the sandbox if present (unless disabled by flags):
    • providers.jsonc (provider config)
    • config.json (project list)
    • Each file is seeded independently from the first root that has it ($MUX_ROOT, then ~/.mux-dev, then ~/.mux), so a root with only config.json doesn't drop provider config
  • Provider credential env vars are stripped from the child processes' env when they could silently override or mismatch the intended setup: all of them with --clean-providers (including Bedrock's AWS_REGION and AWS_BEARER_TOKEN_BEDROCK; shared AWS credentials like AWS_PROFILE are kept); otherwise only *_BASE_URL env vars that would shadow a seeded providers.jsonc entry that has an apiKey but no explicit baseUrl (API key env vars are always kept so env-key fallback still works)
  • Picks free ports:
    • Vite devserver port (used by the renderer)
    • Electron remote debugging port (optional)
  • Disables tutorials by default inside the sandbox (MUX_ENABLE_TUTORIALS_IN_SANDBOX=1 opts back in)
  • Runs make dev with:
    • MUX_ROOT=<temp>
    • MUX_VITE_PORT=<free-port>
  • Waits for Vite to be reachable, then runs make build-static (Electron expects dist/splash.html)
  • Launches Electron (bunx electron .) with:
    • MUX_ROOT=<temp>
    • MUX_DEVSERVER_HOST=127.0.0.1
    • MUX_DEVSERVER_PORT=<vite-port>
    • MUX_SERVER_PORT=0 by default (avoids EADDRINUSE if your config.json pins apiServerPort)
    • CMUX_ALLOW_MULTIPLE_INSTANCES=1 (so you can run alongside another dev instance)

Agent usage with bash.monitor

When launching an Electron sandbox for dogfooding, prefer a monitored background bash so Mux wakes the workspace on Vite/Electron readiness or startup failures without manual polling.

bash({
  script: "make dev-desktop-sandbox",
  display_name: "Desktop Sandbox",
  run_in_background: true,
  timeout_secs: 1800,
  monitor: {
    filter: "Vite|ready|localhost|Electron|ERROR|EADDRINUSE|failed|Failed",
    cooldown_ms: 1000,
    max_events: 5,
  },
});

After a readiness wake, use the sandbox output/ports shown in the matched logs to connect with the Electron or agent-browser workflow. Use task_await only when the wake line is not enough context.

Options

# Start with a clean instance (do not copy providers or projects)
make dev-desktop-sandbox DEV_DESKTOP_SANDBOX_ARGS="--clean-providers --clean-projects"

# Skip copying providers.jsonc
make dev-desktop-sandbox DEV_DESKTOP_SANDBOX_ARGS="--clean-providers"

# Clear projects from config.json (preserves other config)
make dev-desktop-sandbox DEV_DESKTOP_SANDBOX_ARGS="--clean-projects"

# Use a specific root to seed from (default: per-file from $MUX_ROOT, ~/.mux-dev, ~/.mux)
SEED_MUX_ROOT=~/.mux-dev make dev-desktop-sandbox

# Keep the sandbox root directory after exit (useful for debugging)
KEEP_SANDBOX=1 make dev-desktop-sandbox

# Pin Vite port
VITE_PORT=5174 make dev-desktop-sandbox

# Control how long we wait for Vite to come up (ms)
VITE_READY_TIMEOUT_MS=120000 make dev-desktop-sandbox

# Re-enable tutorials for sandbox dogfooding
MUX_ENABLE_TUTORIALS_IN_SANDBOX=1 make dev-desktop-sandbox

# Enable/pin Electron remote debugging port (defaults to an auto-picked free port)
ELECTRON_DEBUG_PORT=9223 make dev-desktop-sandbox

# Disable Electron remote debugging entirely
ELECTRON_DEBUG_PORT=0 make dev-desktop-sandbox

# Override the internal API server port (defaults to 0/random for sandboxes)
MUX_SERVER_PORT=3772 make dev-desktop-sandbox

# Override which make binary to use
MAKE=gmake make dev-desktop-sandbox

Optional: deeper Electron isolation (MUX_E2E=1)

Even with a unique MUX_ROOT, Electron's userData directory (localStorage, window state, single-instance lock, etc.) is not automatically relocated unless MUX_E2E=1 is set.

If you want full isolation (including userData), run:

MUX_E2E=1 make dev-desktop-sandbox

Security notes

  • providers.jsonc may contain API keys.
  • The sandbox root directory is created on disk (usually under your system temp dir).
  • This flow intentionally does not copy secrets.json.

When not to use it

  • Single-instance development

Prerequisites

Electron development environment

Limitations

  • Requires system-level FFmpeg or similar dependencies

How it compares

It automates the isolation of configuration and state for multiple instances, preventing credential and port conflicts.

Compared to similar skills

dev-desktop-sandbox side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
dev-desktop-sandbox (this skill)02moReviewAdvanced
kool-cli16moReviewBeginner
k8s-vind16moReviewIntermediate
webapp-testing3533moReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

kool-cli

kool-dev

Docker development environment CLI. Use for managing containers (start/stop/restart), executing commands in services, viewing logs, and running project scripts from kool.yml.

12

k8s-vind

rohitg00

Manage vCluster (virtual Kubernetes clusters) instances using vind. Use when creating, managing, or operating lightweight virtual clusters for development, testing, or multi-tenancy.

10

webapp-testing

anthropics

Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

353585

resolve-conflicts

antinomyhq

Use this skill immediately when the user mentions merge conflicts that need to be resolved. Do not attempt to resolve conflicts directly - invoke this skill first. This skill specializes in providing a structured framework for merging imports, tests, lock files (regeneration), configuration files, and handling deleted-but-modified files with backup and analysis.

81334

telegram-bot-builder

davila7

Expert in building Telegram bots that solve real problems - from simple automation to complex AI-powered bots. Covers bot architecture, the Telegram Bot API, user experience, monetization strategies, and scaling bots to thousands of users. Use when: telegram bot, bot api, telegram automation, chat bot telegram, tg bot.

106130

dev-browser

SawyerHood

Browser automation with persistent page state. Use when users ask to navigate websites, fill forms, take screenshots, extract web data, test web apps, or automate browser workflows. Trigger phrases include "go to [url]", "click on", "fill out the form", "take a screenshot", "scrape", "automate", "test the website", "log into", or any browser interaction request.

53176

Search skills

Search the agent skills registry