claude-in-chrome: `type` silently drops leading characters and `form_input` silently no-ops on Outlook Web recipient field

Summary

Two separate silent-failure modes when driving the compose form on outlook.live.com with the
Claude in Chrome tools. Both produce a wrong result with no error, and the second one actively
reports success. On any send/submit flow the consequence is unrecoverable: the form is submitted
with a truncated value, or the agent believes a field was filled when it was not.

Environment

• Claude Code with the Claude in Chrome extension (mcp__claude-in-chrome__*)
• Site: https://outlook.live.com/mail/0/ — new message compose, "Para" (To) recipient field
• OS: Windows 11 Pro 26100 · Chrome
• Date observed: 2026-08-27

---

Bug 1 — computer action type drops the leading characters

Steps

1. Open outlook.live.com, click Novo email.
2. Click the Para (To) field — targeted by ref from read_page/find, so the element is

confirmed correct.

1. computer → action: "type", text: "comercial@exemplosite.com.br" (28 characters).

Expected — the field contains comercial@exemplosite.com.br.

Actual — the field contains ite.com.br. The first 18 characters are dropped; only the
trailing 10 survive. The tool echoes the full string in its output as if it had been typed, and
raises no error.

This is real data loss, not a rendering/scroll artifact. Verified two ways:

• Pressing Home to move the caret to position 0 still renders the truncated value from the left

edge.

• Committing the recipient with Return produces an invalid recipient chip carrying the

truncated value with an error badge — i.e. the truncation reached the application state, not
just the display.

Reproduced 3× with these variations, all identical:

| Variation | Result |
|---|---|
| click (by ref) → type full string | truncated to last 10 chars |
| click → wait 3 s → type full string | truncated to last 10 chars |
| click → wait 2 s → type "c" → wait 3 s → type remaining 27 chars | truncated to last 10 chars |

The third variation is the informative one: it rules out "the field had not received focus yet".
The loss happens after the first keystroke, which is consistent with the field being an async
people-picker that re-renders on first input and discards buffered keystrokes.

Side effect: after this happens, continuing to interact with the compose form can silently
clear an already-filled Subject field.

Does not reproduce with a human paste. Pasting the same 28-character string into the same
field works every time, repeatedly, in the same session. That contrast localises the problem to
how keystrokes are delivered, not to the site or the network.

---

Bug 2 — form_input reports success but the value never lands ⚠️ higher severity

Steps

1. Same compose form, same Para field, obtained via find.
2. form_input → { ref: "<ref>", value: "comercial@exemplosite.com.br" }

Tool output

Set text value to "comercial@exemplosite.com.br" (previous: "")

Actual — the field renders empty. The value is not present visually and never reaches the
application state.

This looks like the classic React controlled-component problem: assigning element.value directly
does not notify React, so the component re-renders from its own state and discards the assignment.

Why this is the worse of the two bugs: Bug 1 produces a visibly wrong value that a careful
agent can catch by re-reading the field. Bug 2 returns an explicit success message for a write
that did not happen. An agent that trusts the tool's own return value — which is the reasonable
thing to do — proceeds on a false premise with nothing to catch it.

---

Impact

form_input is the documented escape hatch for exactly this situation ("Set the value of a form
element … handles input/textarea/select/checkbox/contenteditable"). With both the typing path and
the direct-set path failing silently on the same field, there is no reliable way to fill a
recipient on one of the most widely used webmail clients — and no signal that anything went wrong.

In the session where this was found, the failure was caught only because the agent screenshotted
and verified every field before clicking the send button. Without that check the message would
have been sent to a truncated address. In one earlier attempt using fixed coordinates (see the
minor note below) the entire message body was typed into the recipient field, producing dozens
of invalid recipient chips — one click away from being sent.

Suggested fixes

1. form_input: use the native value setter plus a dispatched input/change event

(Object.getOwnPropertyDescriptor(window.HTMLInputElement.prototype, 'value').set) so
controlled components register the write — then read the value back and fail loudly if it did
not take, instead of reporting success unconditionally.

1. type: consider a clipboard-paste path for long strings, or re-read and retry when the

resulting field value does not match the requested text.

1. Either way, verify-after-write would turn both of these from silent corruption into an

honest error, which is the difference that matters for autonomous use.

Minor, related

Page zoom changed between two tool calls in the same session, so coordinates captured from an
earlier screenshot silently addressed the wrong elements. Element refs were unaffected. It may
be worth stating in the standalone computer tool description that coordinates are only valid
against the immediately preceding screenshot — browser_batch documents this, but computer
does not, and that is where the coordinate is easiest to reuse by mistake.