by ZaneL1u
Let AI agents debug the WebViews inside your app and your H5 pages — on real users' phones, over MCP.
# Add to your Claude Code skills
git clone https://github.com/ZaneL1u/remote-webview-debuggerGuides for using ai agents skills like remote-webview-debugger.
See how remote-webview-debugger compares with popular alternatives.
remote-webview-debugger is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by ZaneL1u. Let AI agents debug the WebViews inside your app and your H5 pages — on real users' phones, over MCP. It has 51 GitHub stars.
remote-webview-debugger's catalog security scan is still queued. You can run an instant dependency and prompt-injection check now with the "Scan for vulnerabilities" button above.
Clone the repository with "git clone https://github.com/ZaneL1u/remote-webview-debugger" and add it to your Claude Code skills directory (see the Installation section above).
remote-webview-debugger is primarily written in TypeScript. It is open-source under ZaneL1u on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh remote-webview-debugger against similar tools.
No comments yet. Be the first to share your thoughts!
Available after the catalog security scan passes.
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.
The deep catalog scan for this skill is still queued. Run an instant dependency check now instead.
See comparison
Let AI agents debug the WebViews inside your app and your H5 pages — on real users' phones, remotely, over MCP.
debugger.site · Live demo · Docs
English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Français | Deutsch | Português (Brasil) | Русский | العربية
A bug that only happens on one user's phone, inside a WeChat-style super app or your own app's WebView, is the hardest kind to debug: no USB cable, no remote-debugging port, no way to reproduce it on your machine. Remote WebView Debugger puts that page in front of your AI agent instead.
Claude Code / Cursor ──MCP (HTTPS)──▶ Gateway ──WebSocket──▶ SDK in the page ──▶ DOM · console · network
▲
Web console
Three steps: run the gateway, add the SDK to a page, point your agent at the gateway.
docker run -d --name rwd -p 8080:8080 -v rwd-data:/data \
-e RWD_ADMIN_PASSWORD='change-me' \
ghcr.io/zanel1u/remote-webview-debugger:latest
Open http://<your-host>:8080 and sign in as admin with that password. Leave RWD_ADMIN_PASSWORD out and a random one is printed once in docker logs rwd. The image is Alpine-based (linux/amd64 and linux/arm64), embeds the console and the SDK, and keeps everything in the rwd-data volume; to upgrade, docker pull the new tag and recreate the container.
Settings you may want, passed with -e (all settings):
| Variable | Purpose |
|---|---|
RWD_ADMIN_EMAIL |
Owner login name (default admin) |
RWD_PUBLIC_URL |
The address phones and agents use, e.g. https://rwd.example.com/v1, when it differs from the one in your browser |
RWD_LANG=zh |
MCP tool descriptions and results in Chinese |
RWD_DATABASE_URL |
postgres://… to use Postgres instead of SQLite |
RWD_TRUST_PROXY=1 |
Only behind your own reverse proxy: take the client IP and scheme from X-Forwarded-* |
rwd_<version>_<os>_<arch>.tar.gz for Linux and macOS: unpack it and run ./rwd serve --addr :8080.deploy/platform adds a Caddy in front: behind your own TLS proxy, or serving HTTPS itself with a Let's Encrypt certificate (RWD_DOMAIN=<host>).make -j16 (needs Go and Node), then gateway/bin/rwd-<os>-<arch> serve --addr :8080.Create a project in the console to get an app key, then add the SDK with your gateway's address:
<script src="https://cdn.jsdelivr.net/npm/remote-webview-debugger@0.3.0/dist/sdk.js"></script>
<script>RemoteWebviewDebugger.run('https://rwd.example.com/v1', 'rwd_pk_…')</script>
The SDK is the npm package remote-webview-debugger: load it from jsDelivr as above or from unpkg (https://unpkg.com/remote-webview-debugger@0.3.0/dist/sdk.js), or npm install remote-webview-debugger and import { run } from 'remote-webview-debugger'. Your gateway also serves the copy it embeds at /v1/sdk.js.
In an app, inject the same script at document start from native code (iOS WKUserScript, Android addDocumentStartJavaScript): see native integration and the guide built into the console.
Create an API key in the console (one key reaches every device), then:
claude mcp add --transport http rwd https://rwd.example.com/v1/mcp --header "Authorization: Bearer rwd_sk_live_…"
…and ask: "Connect to device K7Q2-9M4X and find out why the checkout total shows --."
The gateway speaks plain HTTP and works fine that way: the SDK picks ws:// or wss:// from the gateway address, and the console and MCP work over either. What decides is the page you debug. Browsers and WebViews don't let an https:// page load http:// scripts or open ws:// connections (mixed content), even when sdk.js itself comes from the HTTPS CDN.
| The page you debug | Gateway over plain HTTP |
|---|---|
http://: local dev server, intranet test environment |
✅ Works |
https:// in a browser or an iOS WKWebView |
❌ Blocked as mixed content: give the gateway HTTPS |
https:// in an Android WebView |
⚠️ Only if the app calls setMixedContentMode(MIXED_CONTENT_ALWAYS_ALLOW), in debug builds only |
Over plain HTTP, API keys and console passwords travel unencrypted, so keep it to a network you trust. To get HTTPS, run the Compose stack with RWD_DOMAIN=<host> (automatic certificate), or put the container behind your own TLS proxy and add -e RWD_TRUST_PROXY=1.
observe / interact / advanced), optional auto-approve, screen lock while the agent operates, take over / hand back / end, confirmation for sensitive actions (data-rwd-confirm).data-rwd-mask and configurable selectors / patterns are masked in snapshots, screenshots, console and network data. The audit log records who did what, without page content.run({ lang }), and the agent side follows RWD_LANG. The page SDK takes your own language packs and wording, and restyles through CSS variables (SDK languages and styling).| Path | What |
|---|---|
gateway/ |
Go gateway: page WebSocket, REST and console auth, MCP server, audit, metrics |
sdk/ |
Page SDK (sdk.js) and its in-page UI |
packages/chobitsu/ |
Vendored chobitsu plus our page-side engine in src/engine/ |
console/ |
Web console (React, Vite) |
website/ |
debugger.site, with the interactive demo |
examples/ |
A multi-page demo shop and a macOS app that hosts WKWebViews like an iOS app |
deploy/platform/ |
Docker Compose deployment |
docs/ |
Architecture, protocol, native integration, releasing |
The page SDK and the gateway are released separately, each with its own version, tag (sdk-vX.Y.Z, gateway-vX.Y.Z) and changelog: SDK, gateway. A gateway release comes with rwd binaries for Linux and macOS and the image ghcr.io/zanel1u/remote-webview-debugger. See GitHub Releases and, for maintainers, releasing.
make -j16 check # gateway tests, SDK typecheck + Playwright tests, console build
cd console && PORT=8080