[BUG] [claude-in-chrome] Typed text mis-inserts into the document body during the Google Docs comment workflow (focus/state race + mid-task connection drops)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Title: [claude-in-chrome] Typed text mis-inserts into the document body during the Google Docs comment workflow (focus/state race + mid-task connection drops)
Environment: Claude Code + claude-in-chrome MCP, macOS, Google Docs (multi-tab document), Suggesting mode.
Task: paste anchored comments — for each: Cmd+F to select an anchor phrase → click the "+" comment button → type the comment → submit.
Problems observed:
- Typed text repeatedly landed in the DOCUMENT BODY instead of the search box / comment box, even right after a screenshot that appeared to show correct focus. The screenshot lags the real focus state, so there is a race window between "verify focus" and "type".
- The browser connection dropped mid-task ("Multiple Chrome browsers connected — none selected") BETWEEN a focus-confirming screenshot and the next type, so keystrokes hit the wrong target. Required re-running switch_browser to recover.
findelement refs went stale after Docs tab switches and pointed to elements in a different tab.- The comment card's submit button was frequently off-screen; scrolling the card scrolled the whole document instead.
Impact: erroneous suggested edits inserted into a live shared production document (only recoverable because Suggesting mode was on). Significant wasted time. User contrasted this unfavorably with Codex's browser control.
Likely root cause: pixel/coordinate + screenshot control is non-deterministic vs DOM-level control; there is no primitive to assert the focus target before typing; no resilience to mid-task connection drops.
Requests: (a) a way to assert/guarantee the focus target before type; (b) a DOM-level "type into this element" primitive; (c) don't silently drop and re-prompt browser selection mid-session; (d) more robust Google Docs multi-tab handling.
What Should Happen?
Title: [claude-in-chrome] Typed text mis-inserts into the document body during the Google Docs comment workflow (focus/state race + mid-task connection drops)
Environment: Claude Code + claude-in-chrome MCP, macOS, Google Docs (multi-tab document), Suggesting mode.
Task: paste anchored comments — for each: Cmd+F to select an anchor phrase → click the "+" comment button → type the comment → submit.
Problems observed:
- Typed text repeatedly landed in the DOCUMENT BODY instead of the search box / comment box, even right after a screenshot that appeared to show correct focus. The screenshot lags the real focus state, so there is a race window between "verify focus" and "type".
- The browser connection dropped mid-task ("Multiple Chrome browsers connected — none selected") BETWEEN a focus-confirming screenshot and the next type, so keystrokes hit the wrong target. Required re-running switch_browser to recover.
findelement refs went stale after Docs tab switches and pointed to elements in a different tab.- The comment card's submit button was frequently off-screen; scrolling the card scrolled the whole document instead.
Impact: erroneous suggested edits inserted into a live shared production document (only recoverable because Suggesting mode was on). Significant wasted time. User contrasted this unfavorably with Codex's browser control.
Likely root cause: pixel/coordinate + screenshot control is non-deterministic vs DOM-level control; there is no primitive to assert the focus target before typing; no resilience to mid-task connection drops.
Requests: (a) a way to assert/guarantee the focus target before type; (b) a DOM-level "type into this element" primitive; (c) don't silently drop and re-prompt browser selection mid-session; (d) more robust Google Docs multi-tab handling.
Error Messages/Logs
Steps to Reproduce
Title: [claude-in-chrome] Typed text mis-inserts into the document body during the Google Docs comment workflow (focus/state race + mid-task connection drops)
Environment: Claude Code + claude-in-chrome MCP, macOS, Google Docs (multi-tab document), Suggesting mode.
Task: paste anchored comments — for each: Cmd+F to select an anchor phrase → click the "+" comment button → type the comment → submit.
Problems observed:
- Typed text repeatedly landed in the DOCUMENT BODY instead of the search box / comment box, even right after a screenshot that appeared to show correct focus. The screenshot lags the real focus state, so there is a race window between "verify focus" and "type".
- The browser connection dropped mid-task ("Multiple Chrome browsers connected — none selected") BETWEEN a focus-confirming screenshot and the next type, so keystrokes hit the wrong target. Required re-running switch_browser to recover.
findelement refs went stale after Docs tab switches and pointed to elements in a different tab.- The comment card's submit button was frequently off-screen; scrolling the card scrolled the whole document instead.
Impact: erroneous suggested edits inserted into a live shared production document (only recoverable because Suggesting mode was on). Significant wasted time. User contrasted this unfavorably with Codex's browser control.
Likely root cause: pixel/coordinate + screenshot control is non-deterministic vs DOM-level control; there is no primitive to assert the focus target before typing; no resilience to mid-task connection drops.
Requests: (a) a way to assert/guarantee the focus target before type; (b) a DOM-level "type into this element" primitive; (c) don't silently drop and re-prompt browser selection mid-session; (d) more robust Google Docs multi-tab handling.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.19367.0 (1a5be1) 2026-07-07T05:45:41.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_