Dev Serve
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill mostly matches its stated purpose, but it can expose dev servers broadly and edit shared Caddy/project configuration with limited safety checks.
Install only if you are comfortable with a helper that starts long-running dev servers, modifies your Caddyfile and project Vite config, and may expose raw dev ports unless your firewall blocks them. Review the script, back up your Caddyfile, use DNS-safe project names, and stop services with dev-serve down when finished.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The dev server may be reachable directly on its raw port, bypassing Caddy/TLS/routing controls, depending on the machine's network and firewall.
The generated dev command for supported frameworks binds the dev server to all network interfaces, even though the stated architecture routes traffic through Caddy to localhost.
echo "$pm run dev -- --host 0.0.0.0 --port $port"
Bind dev servers to 127.0.0.1 by default, require an explicit opt-in for 0.0.0.0, and advise users to firewall the 5200+ port range.
Unusual project names or domain values could corrupt the shared Caddyfile, delete unrelated lines, or break other routes when starting or stopping a dev server.
Repo-derived names and domains are inserted into Caddyfile edits and sed regexes without visible validation or escaping, and removal can delete any line containing the subdomain.
name=$(basename "$repo_abs") ... sed -i "/# ${name} (dev-serve)/,/^}/d" "$CADDYFILE" ... sed -i "/${subdomain}/d" "$CADDYFILE"Validate repo names as DNS-safe labels, escape values used in grep/sed, maintain a clearly bounded managed section, and create backups before modifying the Caddyfile.
Running this on an untrusted repository can execute arbitrary commands defined by that repository's dev script.
The script reads the selected repository's package.json dev script and executes it in a tmux session, which is expected for this tool but still runs project-provided code.
dev_script=$(jq -r '.scripts.dev // empty' "$repo/package.json" 2>/dev/null) ... tmux send-keys -t "$session_name" "$dev_cmd" C-m
Use it only with trusted projects, review package.json scripts first, and consider sandboxing untrusted code.
If misdirected or pointed at a non-local admin endpoint, it could change proxy configuration or send the Caddyfile to an unintended Caddy admin API.
The helper uses the Caddy admin API to load the full Caddyfile. This is purpose-aligned, but it is privileged local service control.
curl -sf -X POST "${CADDY_ADMIN}/load" ... --data-binary "@${CADDYFILE}"Keep CADDY_ADMIN on localhost unless intentionally managing a trusted endpoint, and back up the Caddyfile before use.
The dev server, Caddy route, and local state can persist until explicitly stopped, consuming resources and keeping the service reachable.
The skill intentionally starts a detached tmux session so the dev server continues running after the command returns.
tmux new-session -d -s "$session_name" -c "$repo_abs"
Use dev-serve ls/down to monitor and stop sessions, and verify stale routes are removed when work is finished.
Automated prerequisite checks may not catch missing tools or configuration, and users must rely on manually reviewing the helper before making it executable.
The skill is installed by manually copying an executable helper script; registry metadata shows no install spec and does not declare the tmux/jq/curl requirements described in SKILL.md.
cp scripts/dev-serve.sh ~/.local/bin/dev-serve chmod +x ~/.local/bin/dev-serve
Inspect the full script before copying it, install only from a trusted source, and ensure tmux, jq, curl, Caddy, and DEV_SERVE_DOMAIN are configured.