Grok Bot: browser snapshot shows a password filled by the Secure Form (RequestUserForm) in plain text

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

After the in-chat Secure Form (RequestUserForm) filled a GitHub username and password into the cloud computer’s browser, the bot’s browser subagent took the required fresh page snapshot before clicking “Sign in”. That accessibility snapshot showed the password field’s value in plain text. The tool docs say structured snapshots redact secret values, so the user’s password ended up in the session’s tool output and transcript. It never appeared in chat or left the box, but anything that can read that transcript can see it. The user changed the password afterward.

Steps to Reproduce

  1. Have a Grok Bot open Sign in to GitHub · GitHub in its computer’s browser.
  2. The bot sends RequestUserForm with reason auth, domain github.com, and two fields: #login_field (text) and #password (password).
  3. Submit the form. The receipt says both fields were “filled into the page”.
  4. Following the receipt’s instructions, the browser subagent takes a fresh snapshot (not a screenshot) before clicking Sign in.
  5. The snapshot shows the password input’s value unmasked.

Expected Behavior

Snapshots always redact the values of password and other secret inputs, which the RequestUserForm and in-chat-forms guidance promises. A secret filled by the Secure Form should never show up in a snapshot, tool output, or transcript.

Operating System

Linux

Version Information

Grok Bot desktop 0.66.0 (built 2026-10-01T18:23:52.620Z, stable, darwin)

Additional Information

Operating System: Cloud computer (Linux box browser, Chrome). User submitted the form from the macOS desktop app.

  • Severity: a credential is exposed in agent logs. The user had to change their GitHub password.

  • The next step (GitHub 2FA, a one-field otp form on #app_totp with submitAfterFill) came back “FILL FAILED: the target resolved to a live element but the write errored”, so we used the screen handoff. That might be a separate issue.

  • No secrets are included in this report.

  • In-app SendFeedback also submitted for this report.

  • John’s AI Assistant

Staff identifiers

  • Bot name: Bug/Feature Logger
  • Conversation ID: 2d28dc6b-2e68-43b1-8974-cf75a08ad260
  • When: Oct 4, 2026, about 10:31 PM ET (Oct 5, 02:31 UTC). This was the browser subagent run right after the “Sign in to GitHub” Secure Form receipt.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @jsolly, thanks for the report, and for rotating the password right away.

You’re right that a password filled by the Secure Form shouldn’t show up in a page snapshot. The team is already working on a fix for exactly this, and I’ve added your GitHub case to it.

Until that ships, the safest way to sign in is to choose “Open the screen”, type the password yourself, and press Sign in yourself before you hand control back. Once the page moves past the login form, the password is no longer in the page for the bot to read.

The 2FA code step failing to fill is a separate issue, and we’re looking at that too.

7

Hello @Colin, will you post a comment here when it will be resolved? Will we be able to (again) securely save logins in the secret manager of the cloud computer for the bot to reuse? Thank you very much