# Chrome MCP Devtools

> Connect Codex to Windows Chrome through Chrome DevTools MCP, verify the remote debugging port, and continue browser inspection or interaction. Use when the user asks to use chromeMCP or Chrome DevTools MCP, wants browser-based verification, or needs Chrome launched from WSL with remote debugging on port 19222.

- Skill: `satoru314/chrome-mcp-devtools` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add satoru314/chrome-mcp-devtools`
- Raw SKILL.md: https://api.skillmd.com/api/skills/satoru314/chrome-mcp-devtools/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Satoru314 (https://skillmd.com/u/satoru314)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/satoru314/chrome-mcp-devtools

---


# Chrome MCP DevTools

Use this skill when Codex needs to drive or inspect a real Chrome session through Chrome DevTools MCP, especially in a WSL to Windows setup.

## Startup Workflow

1. Check whether Chrome remote debugging is already reachable.

```sh
curl -s --max-time 1 http://127.0.0.1:19222/json/version
```

- If the response is non-empty, continue to MCP tool discovery.
- If the response is empty or times out, start Chrome from Windows and retry.

2. Start Windows Chrome with a short timeout and quick retries.

```sh
timeout 5 bash -lc '(cd /mnt/c && cmd.exe /c start "" "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=19222 --remote-debugging-address=0.0.0.0 --user-data-dir="C:\tmp\chrome-debug-new" --remote-allow-origins="*") && for i in 1 2 3; do result=$(curl -s --max-time 1 http://127.0.0.1:19222/json/version 2>/dev/null); [ -n "$result" ] && echo "Connected at attempt $i" && break; [ $i -lt 3 ] && sleep 1; done; [ -n "$result" ] || echo "FAILED"'
```

- Keep the timeout short. Do not wait indefinitely.
- If this still fails, stop and report: `接続失敗: Chrome のデバッグポート http://127.0.0.1:19222/json/version に繋がりません。Chrome の起動状態を確認してください。`

3. Discover the Chrome MCP tool namespace available in the current Codex environment.

- Look for tool names containing `chrome-devtools`, `chrome_devtools`, or both `chrome` and `devtools`.
- Do not promise browser actions until both conditions are true:
  - The debugging port responds.
  - The Chrome MCP tools are available in Codex.

4. Confirm control of the browser before doing deeper work.

- Prefer a non-destructive tool first:
  - page listing
  - screenshot
  - snapshot
- Report the current page or visible screen, then continue with the user's actual task.

## Operating Rules

- Prefer immediate execution over asking for confirmation unless the environment explicitly requires approval.
- Prefer short retries over long passive waits.
- If multiple pages are open, list pages and select the correct one before clicking or typing.
- Before interacting with the DOM, capture a snapshot when the MCP toolset supports it.
- For UI debugging, inspect console messages and network requests after reproducing the issue.
- If the user asks only for connection setup, stop after confirming control with a screenshot or equivalent page state report.

## Failure Handling

- If the debug port is closed after startup, treat it as a Chrome launch failure, not an MCP failure.
- If the debug port is open but MCP tools are missing, tell the user that Chrome DevTools MCP is not connected to Codex and cannot be used yet.
- If the default Windows Chrome path does not exist, report the expected path and adapt the launch command if the user provides a custom install location.
- If the environment is not WSL or not using Windows Chrome, adapt the launch step instead of forcing the Windows-specific command.

## Common Triggers

- `chromeMCP 使って`
- `Chrome DevTools MCP で見て`
- `ブラウザで確認して`
- `devtools で開いて調査して`