Skip to content

feat(browser): sign in in a real window - #139

Merged
httpsphl merged 4 commits into
mainfrom
feat/browser-window
Oct 3, 2026
Merged

httpsphl merged 4 commits into
mainfrom
feat/browser-window

Conversation

@httpsphl

@httpsphl httpsphl commented Oct 3, 2026

Copy link
Copy Markdown
Owner

Builds on #138 (its commit shows here until that one merges).

Google, and other sites that look past the user agent and navigator.webdriver, refuse to sign in to the bot's browser ("This browser or app may not be secure"). That happens even with the owner in control, because the browser is still a headless Edge driven over DevTools. This PR adds a way around it that hides nothing from the site: the owner signs in to the bot's profile in a real Edge window.

Daemon

  • New browser.window {botId}: it closes the headless browser, then starts the same browser with a window, on the same profile, without --remote-debugging-port and on the page the bot was on (browser/window.rs, launch::window). It runs in its own job, so it dies with the daemon.
  • While the window is open, BrowserState.window is true (status closed, control owner), and the bot's tools wait as they do for the owner's hands. browser.list includes the browser. Pausing the bot does not close the window; archiving it kills the window.
  • When the window closes, the browser goes back to the bot. An open browser_ask_owner request is answered Done, and the tool tells the bot to browser_open again because the logins stay.

App

  • Sign in in a window sits next to Take control under the live screen, in the help callout and in the "You are in control" bar. While the window is open, a bar reads "Open in a window" and tells the owner to sign in there and then close it.
  • Texts are in en, pt-BR and es. FakeBotloft supports it. New window.test.tsx.

Measured with Edge 154 (recorded in spec 19): a msedge.exe started with --user-data-dir and no DevTools stays alive as the browser itself and exits a few seconds after its window closes. A cookie set in the window shows up in the headless Edge opened later on the same profile.

Spec: new 21.11 (old 21.11 Marcos becomes 21.12, with the N3.4 milestone), plus updates to 21.7 and 21.3.

Checks: cargo fmt, clippy and the full test suite (twice), and pnpm check. I also checked the panel in the dev preview.

lib/fakeBrowser.ts is now 324 lines, a little over the ~300 guideline.

Manual test with real Claude Code

  1. Ask a bot to open gmail.com in its browser. When it reaches the Google sign-in page, click Sign in in a window in the panel.
  2. An Edge window opens on that page. Sign in, then close the window.
  3. The panel goes back to normal. Ask the bot to open Gmail: it should already be signed in.
  4. Repeat with the bot asking through browser_ask_owner: closing the window should mark the request Done, and the bot should reopen the page.

Some sites refuse to sign in to a browser that tells them a program
drives it. The bot's browser now keeps navigator.webdriver false
(--disable-blink-features=AutomationControlled) and overrides the user
agent with its userAgentData metadata, read once from chrome://version,
so the brands are no longer empty. No script is injected into pages;
outerWidth stays 0. Spec 21.2, 21.3 and 19 record what was measured.
Google and other sites refuse to sign in to the bot's browser even with
the owner in control, because it is still a headless Edge driven over
DevTools. The new browser.window request closes it and opens the bot's
profile in a common Edge window with no DevTools; the owner signs in
there and closes it. The bot's tools wait meanwhile, an open request
for help counts as done when the window closes, and the next tool
reopens the headless browser on the same profile, logins included.
The panel offers "Sign in in a window" next to "Take control".
Spec 21.11 (new), 21.7, 21.3 and 19.
Edge 153 on the CI lists them as Microsoft Edge, Not_A Brand, Chromium.
@httpsphl
httpsphl enabled auto-merge October 3, 2026 19:23
@httpsphl
httpsphl merged commit a473595 into main Oct 3, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant