From e0cf87ce1e295df7c49b090dc19a00b9e84a5f5b Mon Sep 17 00:00:00 2001
From: Rhys Sullivan <39114868+RhysSullivan@users.noreply.github.com>
Date: Wed, 19 Aug 2026 16:00:21 -0700
Subject: [PATCH] Drop the e2e assertion contradicting the Google scope
 allowlist

---
 e2e/scenarios/first-party-oauth.test.ts | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/e2e/scenarios/first-party-oauth.test.ts b/e2e/scenarios/first-party-oauth.test.ts
index 5a8d4fc57..f0473784a 100644
--- a/e2e/scenarios/first-party-oauth.test.ts
+++ b/e2e/scenarios/first-party-oauth.test.ts
@@ -221,9 +221,14 @@ scenario(
       expect(google.origin.allowedScopes).toContain(
         "https://www.googleapis.com/auth/meetings.space.readonly",
       );
-      expect(google.origin.allowedScopes).not.toContain(
-        "https://www.googleapis.com/auth/gmail.modify",
-      );
+      // `gmail.modify` stays in the host-enforced allowlist on purpose: a
+      // connection created before the full-Gmail review still declares it, and
+      // `resolveFirstPartyScopes` filters discovered scopes through this list,
+      // so dropping it would break those reconnects — as the legacy-spec case
+      // further down this file asserts. The invariant that new Gmail presets
+      // request `mail.google.com` instead lives in the preset unit tests
+      // (packages/plugins/openapi/.../presets.test.ts), which is where the
+      // request-side scope choice is actually decided.
       expect(google.origin.allowedScopes).toContain("https://mail.google.com/");
       expect(google.origin.allowedScopes).toContain(
         "https://www.googleapis.com/auth/gmail.settings.basic",