Token capture no longer sees a Bearer during the labs.google handoff (NO_FLOW_KEY with PR #13 applied)

[bmbcompanybrazil-maker]

Summary

Since ~2026-09-11 the extension no longer captures a Bearer ya29.* token, even with PR #13 applied (flow.google.com host permissions, captcha on /project/<id> tabs). Every request then fails with NO_FLOW_KEY while /health still reports has_flow_key: true (stale cache).

What I measured (headed Chrome 151, Xvfb, real logged-in PRO profile, PR #13 at c8216f5 plus the sticky-tab fix)

1. chrome.storage.local of the extension service worker: flowKeyStored: false, tokenCapturedAt: null, metrics.lastError: "NO_FLOW_KEY".
2. Driving the handoff manually (labs.google/fx/tools/flow) now lands directly on https://flow.google.com/ (server redirect). No request to aisandbox-pa.googleapis.com carrying Authorization: Bearer was observed during the handoff nor on a full reload of a /project/<id> page (Playwright request listener on the same tab).
3. On project load the app issues only POST flow.google.com/_/AiSandboxAngularFrontend/data/batchexecute (16x) plus SAPISIDHASH-authenticated calls to ogads-pa.clients6.google.com and play.google.com/log. So the page-level RPCs moved to a cookie-authenticated batchexecute path.
4. POST /v1/refresh-tokens nudges the extension (nudged: 1), the extension logs refresh_flow_tab: forcing tab reload + re-capture, but no bearer appears afterwards.
5. The Flow web UI itself keeps working in the same profile (composer with Frames/Start/End, Omni 1.1 Flash, 720p, credits shown), so the account and session are fine; only the token surface the extension relies on is gone.

Why it matters

The webRequest.onBeforeSendHeaders capture (background.js, startsWith('Bearer ya29.')) assumes the ya29 bearer is sent by the page during the labs.google handoff. That assumption no longer holds for this account/region, which makes flow image / flow video unusable even with PR #13.

Possible directions

• Check whether the generation call issued from the UI (composer "Start generation") still goes to aisandbox-pa.googleapis.com with a bearer minted elsewhere (I did not trigger a paid generation while sniffing). If it does, the capture could hook that request instead of the handoff.
• Otherwise the bridge would need to speak the batchexecute dialect with cookies (SAPISIDHASH), which is a larger change.
• Meanwhile, /health should not report has_flow_key: true when the extension has no stored key; that masked the failure for me for a while.

Happy to run more measurements on this profile if useful.

[ai4U23]

Upstream comment draft — kodelyx/flow-agent issue #15 (token capture dead)

Repo: kodelyx/flow-agent · Issue: #15 "Token capture no longer sees a Bearer during the labs.google handoff (NO_FLOW_KEY with PR #13 applied)" · Comment draft:

---

Adding two measurements from a live setup (macOS, Chrome 1xx, real logged-in
account with Flow access, extension v1.2.4 + the three community deltas
[retryTabs/createdTab, flow.google.com permissions, web_accessible_resources],
backend v2.0.7 with the stale-socket failover):

1) A paid generation does NOT emit a capturable Bearer either.
The issue author noted they had not triggered a paid generation while sniffing;
we did. A full 720p/8s UI generation in the same profile produced zero
Authorization: Bearer requests on aisandbox-pa.googleapis.com — consistent
with the batchexecute/SAPISIDHASH finding. has_flow_key stayed false through
the whole generation and after it. So the "hook the generation call instead of
the handoff" idea (option 1a) appears closed.

2) Cookie-only requests are rejected — the Bearer is strictly required.
The extension is a browser-context fetch proxy (credentials:'include', so the
session's cookies ride on every request). We patched out the pre-emptive
NO_FLOW_KEY check and relaxed the backend's token health-gate so a
connected-but-tokenless session could dispatch, then called
GET https://aisandbox-pa.googleapis.com/v1/credits end-to-end:
401 UNAUTHENTICATED. Option 1b (rely on cookies) is closed as well.

Conclusion: both halves of "option 1" are empirically dead; the issue's
option 2 (backend speaking the cookie batchexecute dialect, or some equivalent
that does not need the ya29 Bearer) is the only remaining path on this host.
Our patches were reverted after the test (fail-fast beats 401-churn). If it
helps anyone, the test cost ~1 generation and is fully reproducible.

For completeness: has_flow_key: true can be observed transiently right after a
UI generation click in some sessions (the issue's "stale cache" note) — in
ours it never armed at all post-migration, with all_cookies: 47, flow_domain: 0
on disk.