drpwchen

Kimi Webbridge Lockdown — AI skill for Claude Code

AI community

Lock Kimi WebBridge (or any debugger-based AI browser-control extension) out of your bank, broker and mailbox — guided, reversible ExtensionSettings policy (Edge+Chrome, Windows/macOS).

How to install Kimi Webbridge Lockdown

This entry records only its repository, not the path inside it, so there is no exact command to give. Open drpwchen/kimi-webbridge-lockdown and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Kimi Webbridge Lockdown does

Lock Kimi WebBridge (or any debugger-based AI browser-control extension) out of your bank, broker and mailbox — guided, reversible ExtensionSettings policy (Edge+Chrome, Windows/macOS).

Alternatives in AI

Manifest — Real-time cost observability for OpenClaw agents — track tokens, costs, messages, and model usage 4.1k ★
Design Md Chrome — Chrome extension to extract styles from any website and generate DESIGN.md files and design skills for AI base 2.7k ★
Adopt AI Properly — Workflow recipe — the org-side AI adoption arc, policy to proof, by chaining 4 skills 1.3k ★

README

kimi-webbridge-lockdown

[繁體中文](README.zh-TW.md)

Lock AI browser-control extensions out of your bank, broker, and mailbox — while letting them automate everything else.

The problem

AI coding agents can drive your real browser through extensions (Kimi WebBridge, Claude in Chrome, and similar). Some of these use the `chrome.debugger` API with `` host permissions: they get **your logged-in identity on every site, all at once**.

The counter-intuitive part, confirmed by hands-on testing (2026-08-09, Edge on Windows):

**The per-site "site access" whitelist in the extensions UI does NOT stop debugger-based extensions.** That UI only withholds `host_permissions` (content scripts, webRequest). The `debugger` API permission is granted globally — the extension can still attach to any tab, read the page, and run JavaScript, even on sites you removed from its list.

The only per-host control that actually works is the **enterprise policy layer**: `ExtensionSettings` → `runtime_blocked_hosts`. With it set, the extension gets `Cannot attach to this target` on blocked sites and works normally everywhere else. Verified in both directions on a real setup (13 blocked hosts refused, unblocked automation targets unaffected).

This tool makes that policy a guided, reversible, one-command setup.

What it does

Detects installed extensions holding the debugger permission (the risky class), across all browser profiles.
Lets you pick what to protect: a starter catalog of verified Taiwan bank / broker / Gmail login hosts, plus any host you add (paste the login-page URL — the host is extracted for you).
Backs up the current policy, then merges (never overwrites) your blocked hosts into ExtensionSettings.
Verifies by reading the policy back, and walks you through the live test: blocked site must fail to attach, normal site must still work.
Unblocks selected hosts later (need automation on a blocked site once? remove just that h