Set up and troubleshoot Daytona sandbox environments, which provide isolated spaces for running applications. The skill covers CLI authentication, persistent desktop and server sandboxes, diagnostic logs, shared secrets storage, snapshot refreshes, and environment deletion.
Daytona CLI setup, sandbox debugging, keep a sandbox alive, secrets volume, snapshot refresh. Use when Daytona itself is the problem, not for running tests (see run-tests).
Review the instructions the agent will receive before you install.
Use this skill for Daytona infrastructure, not test placement.
Install the Daytona CLI with brew install daytonaio/cli/daytona, then authenticate:
daytona login
DAYTONA_API_KEY only when
DAYTONA_API_URL=https://app.daytona.io/api is also set; with the key alone
it silently falls back to the saved profile. Scope the team key (Infisical
dev, /openwork-ops) to one command:
DAYTONA_API_URL=https://app.daytona.io/api DAYTONA_API_KEY="$(infisical secrets get DAYTONA_API_KEY --env dev --path /openwork-ops --plain --silent)" <command>.$DAYTONA_CONFIG_DIR/config.json (default: macOS
~/Library/Application Support/daytona/, Linux ~/.config/daytona/,
Windows %APPDATA%\daytona\). Point DAYTONA_CONFIG_DIR at an empty
directory to test the not-logged-in path without touching the real profile.daytona login --api-key on someone's machine for a one-off
task. It overwrites their profile, and with it their browser login, for
every tool. A key printed as *not found* (Infisical CLI 0.28.x exits 0 on a
missing secret) is not a key.pnpm world plan <world> --place daytona prints the identity and
organization in use and warns on a personal one.brew upgrade daytonaio/cli/daytona.To run tests, just use pnpm evals:e2e <slug> — it picks Daytona automatically
when the CLI is authenticated. --local forces local; --daytona requires
Daytona and fails when it is unavailable.
For a PR preview that should open inside Codex and support named scenarios, use preview-my-work. It composes the same maintained world and Daytona primitives with scoped ownership and teardown.
Run bash .devcontainer/test-on-daytona.sh <ref>. The maintained helper uses
the reusable desktop snapshot, starts XFCE/noVNC, Vite, and Electron, and prints
the sandbox and preview URLs. Keep that sandbox for exploration or debugging
instead of reproducing its provisioning commands.
Run bash .devcontainer/test-server-on-daytona.sh <ref>. It starts the separate
MySQL, Den API, and Den Web sandbox and prints public URLs for a desktop sandbox
to consume. Use this helper rather than assembling the server manually.
Inspect /tmp/start-vnc.log, /tmp/vite.log, /tmp/electron.log, and
/tmp/den-api.log in the relevant sandbox. Electron CDP is port 9825; get CDP
and noVNC URLs with:
daytona preview-url <sandbox> -p 9825
daytona preview-url <sandbox> -p 6080
bash .devcontainer/setup-daytona-secrets-volume.sh <local-env> <name>.env
Electron sandboxes mount the reusable secrets volume at /daytona-secrets.
bash .devcontainer/create-daytona-openwork-snapshot.sh
bash .devcontainer/create-daytona-openwork-server-snapshot.sh
daytona delete <sandbox>
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Manage OpenWork feature releases with feature flags, switches that control access to new behavior. Register features before coding, release them by organization and deployment, prepare a global shutdown option, and remove temporary flags after rollout.
Connect OpenCode browser tools to a locally running OpenWork Electron app to inspect its UI, enter a task, and check the response. This skill supports exploration and debugging through CDP, Chrome's remote control protocol.
Check added lines in a change for information identifying customers, prospects, partners, or outside individuals. Report locations and generic remediation without reproducing identities, and escalate cases where the information is already public.
Connects supported AI clients, including Claude Code and Codex, to OpenWork through MCP, a protocol for accessing external tools. It guides account sign-in and verifies that tools for finding and running organization capabilities are available.
Review an outside contributor’s pull request before running its code. Identify concealed behavior, obfuscated code, risky dependencies, and build hooks, with file locations and specific checks for maintainers to follow up.
Create an OpenCode plugin for OpenWork with custom tools and hooks, which run code at specific events. The skill builds the plugin file and adds its entry to the project configuration.