One-time setup for a persistent debug browser on `127.0.0.1:9222` for `dev-browser --connect`. Use when browser work is needed but no reusable debug browser is running yet.
68
84%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Use this skill when dev-browser --connect http://127.0.0.1:9222 fails because
no persistent debug browser is running yet.
Get the user onto one persistent browser/profile that both the human and the
agent reuse. Minimize the Allow remote debugging? popup by keeping one
dedicated debug browser/profile alive.
--user-data-dir as mandatory, not optional. Chrome 136+
basically wants remote debugging to happen from a dedicated profile.dev. Do not
use the user's normal daily Default profile as the source profile.--user-data-dir; do not point 9222 straight at the user's daily Chrome
data dir.open -na "Google Chrome" --args ... for the debug browser.
That starts a separate Chrome instance with the dedicated debug profile
without touching the user's normal Chrome window.Use a dedicated browser/profile with:
--remote-debugging-address=127.0.0.1--remote-debugging-port=9222--user-data-dir=<debug-profile-dir>Sign in once in that dedicated browser and keep reusing it for agent work.
Quick sanity check:
curl -sS http://127.0.0.1:9222/json/versionHealthy output includes a JSON object with webSocketDebuggerUrl. Empty output
or 404 means the wrong process owns 9222.
Then verify dev-browser:
dev-browser --connect http://127.0.0.1:9222 <<'EOF'
const page = await browser.getPage("persistent-main");
console.log(await page.title());
EOFIf dev-browser --connect http://127.0.0.1:9222 still cannot resolve CDP even
though /json/version is healthy, connect with the exact websocket URL:
WS=$(curl -sS http://127.0.0.1:9222/json/version | jq -r '.webSocketDebuggerUrl')
dev-browser --connect "$WS" <<'EOF'
const page = await browser.getPage("persistent-main");
console.log(await page.title());
EOFDefault setup on macOS:
dev, not
the daily Default profile.Local State.9222.python3 - <<'PY'
import json, pathlib
p = pathlib.Path('~/Library/Application Support/Google/Chrome/Local State').expanduser()
obj = json.loads(p.read_text())
for key, val in obj.get('profile', {}).get('info_cache', {}).items():
print(f"{key}\tname={val.get('name')}\tgaia_name={val.get('gaia_name')}")
PY
# Example: if `dev` maps to `Profile 1`, clone `Profile 1`.
mkdir -p "$HOME/.config/google-chrome-debug-profile/Default"
rsync -a --delete \
--exclude='Singleton*' \
--exclude='DevToolsActivePort' \
--exclude='lockfile' \
"$HOME/Library/Application Support/Google/Chrome/Profile 1/" \
"$HOME/.config/google-chrome-debug-profile/Default/"
cp "$HOME/Library/Application Support/Google/Chrome/Local State" \
"$HOME/.config/google-chrome-debug-profile/Local State"
open -na "Google Chrome" --args \
--user-data-dir="$HOME/.config/google-chrome-debug-profile" \
--profile-directory="Default" \
--remote-debugging-address=127.0.0.1 \
--remote-debugging-port=9222That keeps the signed-in identity while still satisfying Chrome's dedicated
--user-data-dir requirement.
Then keep reusing that exact debug browser. Do not point 9222 at your normal
daily Default Chrome profile.
dev-browser --connect http://127.0.0.1:9222 for browser work.persistent-main.9222, identify it with lsof -nP -iTCP:9222 -sTCP:LISTEN,
kill that listener, and relaunch the dedicated debug browser. Do not keep
debugging against a stale 404 or empty /json/version owner.9ec2c8e
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.