Genkan

Genkan lets an MCP client drive the Chromium browser you are already signed into, through a browser extension and a native-messaging host, with no debug port. Code is the source of truth: where a page states a behaviour, the file that owns it is the authority. The security pages say what the bridge promises and where it stops; the rest say how to use, run, and change it.

I want to...

Goal	Read
Install the binary and the extension, and run a first tool call	Quickstart: the CLI
Check that the install is healthy, or read "server not reachable"	CLI: doctor and status
Register the native-messaging host with a browser, or remove it	CLI: doctor --fix and uninstall
Admit an MCP client, or revoke one	CLI: trusted clients
Halt everything now, and release the halt later	CLI: kill switch
Change what tools are allowed to do	CLI: host-owned policy
Read the logs and the audit trail	CLI: logging and audit
Read a doctor row you did not expect, or recover an unreadable kill record	Troubleshooting
Use the bridge from WSL	Troubleshooting: running under WSL
Know what the bridge promises an attacker cannot do, and where that stops	Security: the bar
See what each tool can reach and which confirmation it triggers	Tool risk matrix
Report a security issue	Incident response: reporting
Understand why a security decision was taken before changing it	Security rationale
Know what the extension collects and stores	Privacy policy
See how the processes connect and what crosses each hop	Architecture: overview
Find the cross-process contracts (tool catalogue, error taxonomy, capabilities, protocol version, identity, wire envelopes) the Rust core owns and moon run gen emits as TypeScript	Architecture: protocol boundary contracts
Change something security-relevant	Review bar
Set up the toolchain and run the gate	Development: moon
Run the browser suites against an isolated Chrome, never your own	Tests
Add a tool	Contributing: adding a tool
Cut a release	Releasing
Know which version number moves for which change	Releasing: versions
Weigh publishing the extension to the Chrome Web Store	Releasing: the Chrome Web Store

The pages

Using it

1. Quickstart: install, first use, recommended hardening, uninstalling.
2. CLI: doctor, registration, enrollment, trusted clients, kill switch, policy, logging and audit, and the troubleshooting each answers.
3. Troubleshooting: symptom by symptom, from an unexpected doctor row to kill-record recovery, version skew, and the two WSL modes.
4. Privacy policy: what the extension can access, what it stores, and what it never sends.

Security

5. Security: the one-line promise, what is at stake and who is trusted, the four hops and what gates each, what you confirm, where it stops, per OS.
6. Trust boundaries: the reviewer's ledger, per hop: the mechanism in detail, every accepted residual, the policy ledger, the invariants.
7. Tool risk matrix: every tool's blast radius and protections.
8. Incident response: reporting, triage, mitigation, disclosure.
9. Security rationale: why each decision was taken and what it rejected.
10. Review bar: the surfaces that get extra review, the defaults that fail safe, and what to read before a security-relevant change.

Reference

11. Architecture: components, protocols, data flows, the security model, key constraints, technology choices, and the contracts the Rust core generates.

Contributing

12. Development: toolchain, layout, moon tasks, testing, the container, fuzzing.
13. Releasing: the release-please pipeline, prebuilt archives with checksums and provenance, SBOM, which version moves when, and the Chrome Web Store decision.
14. CONTRIBUTING: the development process, from branch, commit, and sync rules to the squash-merge.
15. Tests: the suites, and the rule that browser tests run only against an isolated Chrome, never your daily browser.