Skip to content

Open sites that refuse Scient's browser identity - #728

Merged
yaacovcorcos merged 2 commits into
mainfrom
claude/browser-site-access-20261101
Nov 1, 2026
Merged

yaacovcorcos merged 2 commits into
mainfrom
claude/browser-site-access-20261101

Conversation

@yaacovcorcos

@yaacovcorcos yaacovcorcos commented Nov 1, 2026 •

Copy link
Copy Markdown
Contributor

What Changed

Scient's browser now opens sites that refuse Electron, such as WhatsApp and monday.com, without a per-site list. This replaces the WhatsApp-only rule from #727.

apps/desktop/src/scient/browser/siteBrowserIdentity.ts has three rules, applied to every browser session, normal and incognito:

  • Requests say plain Chrome in the User-Agent header. The page's own navigator.userAgent stays native.
  • challenges.cloudflare.com keeps the true identity.
  • A site that answers a page load with a 403 gets one reload with the true identity, remembered per host for that session.

This PR also carries upstream's 1280ccd0d2 (pingdotgg/t3code#28603), which pins the clock in one UsageService test. That test used a fixed date that passed the 92-day retention limit at 10:00 UTC on 2026-11-01, so it now fails on every branch, including main, and blocks the merge queue.

Why

Sites refuse opposite things, so neither identity works alone:

A site list only learns after a user is blocked. Changing only the header, with one fallback, covers both groups.

The retry reloads after the refused page arrives. Cancelling the response and calling loadURL shows ERR_BLOCKED_BY_CLIENT on a real address-bar load, and reloading any sooner repeats the previous page. If the user leaves first, the page that arrives instead isn't reloaded.

Measured (Electron 44.10 / Chrome 152, macOS)

Through the real address bar in a dev app, these load: WhatsApp, monday.com, IEEE, ScienceDirect, Science, Wiley, ACS, Oxford, Cell, Taylor & Francis, Sage, Nature, the Cloudflare login, two Cloudflare bot challenges, Overleaf, GitHub, Google, Microsoft and chess.com. A page that refuses everything gets exactly two requests.

Identity sent dash.cloudflare.com/login Full-page challenge ScienceDirect
Whole identity plain Chrome Loops (16 loads, 15 errors) Not tested Not tested
Plain header only Fine Refused 403
This change Fine Fine Fine

The retry was run in real Electron against a local server: a plain refused page, one with a fragment, an empty 403, a redirect to a refused page, a page refused with both identities, and leaving or stopping before arrival.

The hooks cost about 0.02 ms per request, with no visible effect on a 300 MB download or WebSocket stream.

Not proven

  • Sign-in flows other than WhatsApp's QR link, passkeys and video calls.
  • Windows and Linux.
  • ScienceDirect's own retry on this exact reload code: it didn't refuse on the test day, so the retry ran on the local server and in an earlier harness.

Linking WhatsApp by QR worked but took a long time. The busy process was the page's renderer, and the cause is unknown; the hooks aren't it.

On a challenged site's first visit, Back takes two presses because the challenge leaves its own history entry.

Electron keeps one listener per webRequest event per session, so a later listener on these sessions would silently replace this one. Nothing else registers one today.

Documentation impact: None — internal browser behaviour with no documented setting.

Checklist

  • This PR is small and focused
  • I explained what changed and why

🤖 Generated with Claude Code

WhatsApp and monday.com refuse Electron's native identity, while
Cloudflare and some journals refuse a Chrome identity from a browser
that isn't Chrome. Requests now say Chrome by default, a page refused
with a 403 is retried once with the true identity, and Cloudflare's
challenge host keeps the true identity. This replaces the WhatsApp-only
rule from #727.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:M labels Nov 1, 2026
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 1280ccd)
@yaacovcorcos
yaacovcorcos added this pull request to the merge queue Nov 1, 2026
@github-actions

github-actions Bot commented Nov 1, 2026

Copy link
Copy Markdown
Contributor

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider Metric Main baseline This PR Impact PR ceiling
Codex Total thread wire 5.5 KiB 5.5 KiB 0 B (0.0%) 6.8 KiB ✅
Codex Thread snapshot wire 4.2 KiB 4.2 KiB 0 B (0.0%) 4.9 KiB ✅
Codex Live turn WebSocket wire 1.3 KiB 1.3 KiB 0 B (0.0%) 2.0 KiB ✅
Codex Live turn WebSocket decoded 22.4 KiB 22.4 KiB 0 B (0.0%) 24.4 KiB ✅
Codex Live turn messages 2 2 0 (0.0%) 8 ✅
Claude Total thread wire 5.5 KiB 5.5 KiB 0 B (0.0%) 6.8 KiB ✅
Claude Thread snapshot wire 4.2 KiB 4.2 KiB 0 B (0.0%) 4.9 KiB ✅
Claude Live turn WebSocket wire 1.3 KiB 1.3 KiB 0 B (0.0%) 2.0 KiB ✅
Claude Live turn WebSocket decoded 22.7 KiB 22.7 KiB 0 B (0.0%) 24.4 KiB ✅
Claude Live turn messages 2 2 0 (0.0%) 8 ✅

Baseline: 62ab2a9 · PR result: b52e405 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Bounded compact HTTP snapshot with live cursor.

  • Codex decoded thread snapshot: 88.2 KiB
  • Claude decoded thread snapshot: 88.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

Merged via the queue into main with commit d807439 Nov 1, 2026
44 checks passed
@yaacovcorcos
yaacovcorcos deleted the claude/browser-site-access-20261101 branch November 1, 2026 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:M vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants