[BUG] Claude in Chrome: keyboard input never reaches cross-origin iframes (OOPIFs) — clicks work, typing silently fails

Summary

On pages that embed cross-origin iframes (OOPIFs), the Claude in Chrome extension can click elements inside the iframe, but typed text and key events never arrive — computer actions type and key complete without error while the focused field inside the iframe stays empty. This makes entire SPAs unusable for the agent. Verified extensively against GoHighLevel (60k+ business CRM), whose v2 sub-apps (funnel builder, form/survey builder, settings, workflow builder) all render in cross-origin iframes on client-app-*.leadconnectorhq.com inside app.gohighlevel.com.

Environment

• Claude Code (macOS, Darwin 24.6) with claude-in-chrome extension
• Google Chrome 151.x
• Reproduced consistently Aug 4–10, 2026 against app.gohighlevel.com

Repro

1. Log into app.gohighlevel.com, open any sub-account settings page or the funnel builder (content renders in a client-app-*.leadconnectorhq.com iframe).
2. Have the agent click a text input inside the iframe → click lands, field focuses (caret visible).
3. Have the agent type into it → tool reports success, no text appears. key events (e.g. arrow keys, Backspace) also never reach the iframe.
4. Same actions on inputs in the top-level frame work normally.

Root cause (diagnosed)

This is a CDP session-routing asymmetry under Chromium site isolation:

• Mouse events work because Input.dispatchMouseEvent sent on the tab-level session is routed by coordinate hit-testing in the browser process (RenderWidgetHostInputEventRouter) — it reaches whichever renderer's surface is at (x,y), including an OOPIF's separate renderer.
• Keyboard events fail because Input.dispatchKeyEvent / Input.insertText are session-scoped: they're delivered to the renderer of the CDP session that issued them. Dispatched on the tab-level session, they go to the top frame's renderer while DOM focus lives in the OOPIF's separate renderer/process — silently swallowed.

Fix path: chrome.debugger has supported flat sessions since Chrome 125. The extension needs to (1) issue Target.setAutoAttach {flatten: true, filter: [{type: "iframe"}]} on the root session, (2) track Target.attachedToTarget → sessionId per OOPIF (recursively for nested OOPIFs), and (3) dispatch Input.* commands on the session that owns the currently-focused frame. This is exactly what Playwright/Puppeteer do internally (Puppeteer #999/#7049/#7556 chart the same bug and fix on their side), and what browser-use cites as "proper cross-origin iframe support" in their raw-CDP rewrite. vercel-labs/agent-browser hit the identical class (their #279, and #925 fixed via Target.setAutoAttach flatten).

Verification of the diagnosis (Aug 11, 2026)

Connected Playwright (playwright-core, connectOverCDP) to the same Chrome build (151.0.7922.76, dedicated profile with --remote-debugging-port) and drove the exact same GoHighLevel pages:

• frameLocator('iframe[src*="client-app"]') + pressSequentially → per-character keystrokes land inside the client-app-crm-settings.leadconnectorhq.com iframe, verified by inputValue() readback.
• fill() (Input.insertText path) → also lands.
• A second GHL micro-app (calendar-app.leadconnectorhq.com) that ignores even clicks from the extension works fully under Playwright — typed into its search box and the app's list live-filtered, proving the app reacts to properly-routed trusted input.

Same browser, same pages, same CDP Input domain — the only difference is per-frame session routing. This confirms the root cause is the missing OOPIF session attach, not anything GoHighLevel does.

Related

• #69805 — the extension previously also hard-blocked navigation to gohighlevel.com (auto-closed, unresolved); together these make a major CRM platform unusable.
• GoHighLevel's ideas board request for Claude write access has ~292 votes — there's real demand for Claude driving this app, and the API has no write access to the builders, so UI automation is the only path.

Expected

Typing should reach focused elements inside cross-origin iframes, matching click behavior — or, at minimum, the limitation should be documented and surfaced as a tool error instead of silently succeeding.