Summary
kuri can't drive a Tauri desktop app on macOS/Linux: kuri attaches over CDP (Chrome), but Tauri there uses WKWebView / WebKitGTK, which speaks the WebKit Remote Web Inspector (RWI), not CDP. (Windows = WebView2 = Chromium = CDP already works.)
Recommended wire (no kuri code change): a CDP shim on the app's debug bridge
kuri already attaches to any CDP endpoint via CDP_URL / cdp_host:cdp_port and discovers targets via /json/list (src/bridge/bridge.zig). So the app exposes a Chrome-CDP-compatible surface:
GET /json/version + GET /json/list -> [{id, type:"page", url, title, webSocketDebuggerUrl}]- a WS per target implementing a minimal CDP subset (
Runtime.evaluate, Page.captureScreenshot, Input.dispatchMouseEvent, Input.insertText, Accessibility.getFullAXTree) over the webview's evaluateJavaScript + screenshot.
Most of this the app's bridge already does via eval (e.g. codegraff's gui/src-tauri/src/debug_bridge.rs on :9233 - how tdev clicks/types today); the new part is CDP request/response framing. Then CDP_URL=http://127.0.0.1:9233/json/version kuri drives the real Tauri app with kuri's full toolset (snapshot / click-by-ref / type / screenshot / HAR).
Alternative: WKWebView RWI -> CDP bridge
A webinspectord / RWI <-> CDP proxy (the ios-webkit-debug-proxy shape, macOS + Zig) would drive any inspectable WKWebView app, not just ones shipping a bridge. Bigger lift; natural home for a kuri webkit / kuri macos surface.
Optional convenience: kuri tauri
Thin subcommand mirroring kuri ios / kuri android: discover the app's bridge port, set cdp_host/cdp_port, expose snapshot/click/type/screenshot. No new protocol.
Full design + the CDP method-mapping table: docs/integrations/tauri-webview.md.
Summary
kuri can't drive a Tauri desktop app on macOS/Linux: kuri attaches over CDP (Chrome), but Tauri there uses WKWebView / WebKitGTK, which speaks the WebKit Remote Web Inspector (RWI), not CDP. (Windows = WebView2 = Chromium = CDP already works.)
Recommended wire (no kuri code change): a CDP shim on the app's debug bridge
kuri already attaches to any CDP endpoint via
CDP_URL/cdp_host:cdp_portand discovers targets via/json/list(src/bridge/bridge.zig). So the app exposes a Chrome-CDP-compatible surface:GET /json/version+GET /json/list->[{id, type:"page", url, title, webSocketDebuggerUrl}]Runtime.evaluate,Page.captureScreenshot,Input.dispatchMouseEvent,Input.insertText,Accessibility.getFullAXTree) over the webview'sevaluateJavaScript+ screenshot.Most of this the app's bridge already does via eval (e.g. codegraff's
gui/src-tauri/src/debug_bridge.rson:9233- howtdevclicks/types today); the new part is CDP request/response framing. ThenCDP_URL=http://127.0.0.1:9233/json/version kuridrives the real Tauri app with kuri's full toolset (snapshot / click-by-ref / type / screenshot / HAR).Alternative: WKWebView RWI -> CDP bridge
A
webinspectord/ RWI <-> CDP proxy (theios-webkit-debug-proxyshape, macOS + Zig) would drive any inspectable WKWebView app, not just ones shipping a bridge. Bigger lift; natural home for akuri webkit/kuri macossurface.Optional convenience:
kuri tauriThin subcommand mirroring
kuri ios/kuri android: discover the app's bridge port, setcdp_host/cdp_port, expose snapshot/click/type/screenshot. No new protocol.Full design + the CDP method-mapping table:
docs/integrations/tauri-webview.md.