WSL Chrome CDP
AdvisoryAudited by Static analysis on Mar 11, 2026.
Overview
No suspicious patterns detected.
Findings (0)
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.
Other local or permitted network processes that can reach the CDP port may be able to control the debug Chrome profile.
The script intentionally launches Chrome with a DevTools Protocol debugging port, which enables browser control. It uses a separate Debug profile, making the behavior purpose-aligned, but the port should be treated as sensitive.
ps_command='Start-Process "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe" -ArgumentList "--remote-debugging-port=9222","--user-data-dir=C:\\Users\\$env:USERNAME\\AppData\\Local\\Google\\Chrome\\Debug","--no-first-run"'
Use this only on trusted machines, keep port 9222 restricted to localhost/WSL access, avoid broad firewall exposure, and close the debug Chrome instance when done.
Installing or invoking the skill can start a Windows Chrome process from the WSL environment.
The skill executes a Windows PowerShell command from WSL to start Chrome. This is disclosed and necessary for the stated WSL2/Windows integration.
$POWERShell -Command "$ps_command"
Review the script before use and run it only in the intended Windows + WSL2 environment.
Some documented or declared helper paths may not work as written, and users should avoid substituting unreviewed files from elsewhere.
The manifest references scripts paths, including start-chrome-debug.bat, while the provided file manifest only includes enable-browser.sh at the package root and no scripts directory. This looks like a packaging inconsistency.
permissions: - exec:scripts/enable-browser.sh - exec:scripts/start-chrome-debug.bat
Use the included enable-browser.sh only, and ask the maintainer to align the manifest, documentation, and shipped files.