gflow-cli 0.71.1__tar.gz → 0.72.0__tar.gz

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gflow",
-  "version": "0.71.1",
+  "version": "0.72.0",
   "description": "Reusable development and operations workflows for gflow-cli",
   "author": {
     "name": "Flavio Oliva",

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/.env.template

@@ -183,8 +183,9 @@
 # GFLOW_CLI_UI_MODE=auto
 
 # Which Flow frontend gflow drives (#639). auto (default): flow.google.com is the
-# default host for what it can serve today (video t2v, and video i2v from a local
-# --initial-frame, with --project) on every
+# default host for what it can serve today (video t2v; video i2v from a local
+# --initial-frame; video r2v from local --ref files; image t2i; and image i2i from
+# local files — all with --project) on every
 # account; requests it cannot serve yet keep the labs driver on an unmoved
 # account, and a moved account gets the migrated composer for everything ported.
 # flow.google.com: force the migrated composer for everything.

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/AGENTS.md

@@ -42,7 +42,7 @@ by construction, so Codex / Cursor / Aider / `agy` read exactly what Claude Code
 
 ## Project at a glance
 
-- Unofficial Python CLI for [Google Flow](https://labs.google/fx/tools/flow) — drives Veo (image-to-video, text-to-video) and Imagen (text-to-image) generations from the terminal by reverse-engineering Flow's private REST API at `aisandbox-pa.googleapis.com` — and, for accounts Google has moved to `flow.google.com`, that frontend's `batchexecute` wire (text-to-video, image-to-video from a local `--initial-frame`, and reference-to-video from local `--ref` files, today; `GFLOW_CLI_FLOW_HOST`).
+- Unofficial Python CLI for [Google Flow](https://labs.google/fx/tools/flow) — drives Veo (image-to-video, text-to-video) and Imagen (text-to-image) generations from the terminal by reverse-engineering Flow's private REST API at `aisandbox-pa.googleapis.com` — and, for accounts Google has moved to `flow.google.com`, that frontend's `batchexecute` wire (text-to-video, image-to-video from a local `--initial-frame`, reference-to-video from local `--ref` files, and text-to-image/local-file image-to-image, today; `GFLOW_CLI_FLOW_HOST`).
 - Python 3.11+ · `uv`-managed · `hatchling` builds · Playwright Chromium transport · `pyright` strict · `ruff` · `pytest`.
 - Single-package modular monolith. Top-level modules under `src/gflow_cli/`: `api/`, `auth/`, `data/`, `mcp/`, `services/`, `tools/`, `ui/`, `worker/`, `browser_manager.py`, `cli.py`, `_cli_helpers.py`, `diagnostics.py`, `json_output.py`, `media.py`, `profile_lease.py`, `redaction.py`, `storage.py`, `winsec.py`, `cli_project.py`, `cli_character.py`, `cli_credits.py`, `cli_data.py`, `cli_image.py`, `cli_instructions.py`, `cli_models.py`, `cli_movie.py`, `cli_run.py`, `cli_scene.py`, `cli_tools.py`, `cli_video.py`, `chain.py`, `chain_manifest.py`, `cli_doctor.py`, `cli_update.py`, `composition.py`, `config.py`, `errors.py`, `file_integrity.py`, `flow_selectors/`, `update_check.py`, `exceptions.py`, `image_batch.py`, `movie_manifest.py`, `observability.py`, `paths.py`, `profile_store.py`.
 - Command surface: `gflow auth`, `gflow credits` (user/list — read-only Veo balance), `gflow image` (t2i/i2i/batch/upload/upscale), `gflow video` (t2v/i2v/r2v/chain/extend — `extend` continues an existing clip past Flow's 8s ceiling, server-seeded from the source so the join is continuous; no `batch` subcommand; the nonfunctional stub was removed, loop `gflow video t2v`/`i2v` from the shell for multi-clip runs), `gflow character` (create/list/show/rm/voices — reusable project-scoped Flow Character entities), `gflow scene` (create/show — Add Clip / Scenes, with `create --output` for credit-free server-side extended video), `gflow instructions` (persistent Agent-Mode brief cards — add/list/enable/disable/rm/apply/toggle-mode, credits-free, `--project` required), `gflow movie` (run/template — multi-scene manifest pipeline), `gflow tools` (list/show/run — prompt-rewriting tools, also `--tool` on generation commands), `gflow data` (catalog queries), `gflow doctor` (read-only pre-flight diagnostic, exit 33 = findings present), `gflow update` (self-update through the installer that put it here — uv tool / pipx / pip; `--check` only reports; source installs refused, exit 11; deliberately no MCP twin), `gflow project`, `gflow models`, `gflow run`, `gflow mcp` (run/setup — stdio MCP server), and `gflow serve` (Streamable HTTP at `/mcp`; `--transport sse` is deprecated).
@@ -50,7 +50,7 @@ by construction, so Codex / Cursor / Aider / `agy` read exactly what Claude Code
 
 ## Headed-browser dependency (architectural reality)
 
-gflow-cli currently drives Flow via a **real Chrome session managed by Playwright** — `ui_automation` transport. Google's auth + reCAPTCHA stack rejects Playwright's bundled Chromium and most headless approaches. This is the project's defining trade-off:
+gflow-cli currently drives Flow via a **real Chrome session managed by Playwright** — `ui_automation` transport. Google's auth + reCAPTCHA stack rejects browsers that advertise automation, and most headless approaches. This is the project's defining trade-off:
 
 - ✅ Works end-to-end against live Google accounts.
 - ❌ Requires a saved Chrome profile, a display server for one-time login, and ~150 MB for Chromium.

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/CHANGELOG.md

@@ -7,6 +7,90 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.72.0] — 2026-09-09
+
+### Added
+
+- **`gflow image t2i` and local-file `i2i` now run on migrated `flow.google.com`
+  accounts** ([#639](https://github.com/ffroliva/gflow-cli/issues/639)). The Angular
+  composer binds Image mode, Nano Banana 2 / Pro, the four aspect ratios measured on that
+  host (16:9, 4:3, 1:1, 9:16) and counts 1–4,
+  then observes the page-owned `ogiZ0b` `batchexecute` reply and returns the same
+  `GeneratedImage` contract as the labs driver. Local references reuse the measured
+  `maseQ` upload + mention path and are verified in the outgoing submit body before the
+  result is trusted. The migrated page owns reCAPTCHA minting, avoiding the root-grid
+  `RecaptchaError`; unsupported UUID/entity/instruction/Imagen-4 forms still fail before
+  submit rather than silently dropping options.
+
+- **`gflow image batch` is refused on the migrated host instead of failing as selector
+  drift** ([#639](https://github.com/ffroliva/gflow-cli/issues/639)). The batch path
+  drives labs selectors only; it now raises `FlowHostMigratedError` (exit 36) before any
+  submit, rather than running those selectors against `flow.google.com` and reporting
+  exit 23 — which told the user to file a frontend-drift bug about a frontend that was
+  behaving correctly.
+
+### Changed
+
+- **`gflow auth login` closes the browser for you.** It drives your real Google Chrome
+  through Playwright, watches for the completed Flow sign-in, and closes the window itself —
+  the "now close Chrome" step is gone. Closing the window yourself still works and still
+  verifies; it is not an error. On a machine where Playwright cannot resolve a Chrome
+  channel, or where Google rejects the browser anyway, login falls back automatically to the
+  previous flow (Chrome as a plain subprocess, you close the window). **There is no new flag
+  and nothing to choose.**
+  ([spike](docs/superpowers/spikes/2026-09-08-g12-blocks-webdriver-not-playwright.md))
+
+### Fixed
+
+- **The second image in one session no longer falls back to the labs reCAPTCHA mint**
+  ([#673](https://github.com/ffroliva/gflow-cli/issues/673)). Every migrated image run
+  parks its page on `about:blank`, which routes as `labs` — so the page-owned-mint
+  capability, derived from `page.url`, answered `False` on the next call and sent it
+  back to minting on the pooled bootstrap page. The transport now latches the observed
+  host: `gflow image batch`, which runs every prompt through one `FlowApiClient`,
+  generated its first prompt and failed the rest with the exact `RecaptchaError` this
+  release exists to remove.
+- **`--aspect 3:4` is refused on the migrated host rather than reported as selector
+  drift.** The composer's aspect radiogroup was enumerated there with four radios —
+  `crop_16_9`, `crop_landscape`, `crop_square`, `crop_9_16` — and no `crop_portrait`, so
+  a 3:4 request missed its selector and raised exit 23. It is now an unported form
+  (exit 36). The "all five aspect ratios" claim has been corrected to the four measured
+  wherever it appeared.
+- **The exit-36 remediation no longer contradicts the error it accompanies.**
+  `FlowHostMigratedError._default_remediation` still described the migrated host as
+  driving only t2v and local-frame i2v, so an image refusal printed a `detail` saying
+  t2i/i2i are driven directly above a remediation saying they are not. Both it and the
+  class docstring now name the full ported matrix.
+- **`gflow auth login --browser internal` launched a browser configuration measured as
+  rejected.** The bundled-Chromium path shipped with no anti-automation flags, which leaves
+  `navigator.webdriver` set. On 2026-09-08 a browser in that state — real Chrome with the
+  flags removed — was rejected at `/v3/signin/rejected` 17.5 s into the flow, while the same
+  browser *with* the flags signed in normally. Bundled Chromium was measured only in the
+  flagged configuration, so its unflagged rejection is inferred from the shared signal, not
+  observed directly. It now passes
+  `--disable-blink-features=AutomationControlled`, `ignore_default_args=["--enable-automation"]`
+  and `chromium_sandbox=True` — the last of which also removes Chrome's cosmetic *"You are
+  using an unsupported command-line flag"* banner — and signs in on the real OS window
+  instead of an emulated 1920×1080 viewport that pushed Google's sign-in form off-screen on
+  smaller or scaled displays.
+- **Setting `CHROME_BINARY` no longer makes Playwright's `channel="chrome"` look resolvable
+  when it is not.** The availability check treated the variable as proof, passed, and then
+  failed at launch with *"Chromium distribution 'chrome' is not found"*. Playwright honours a
+  custom binary only via `executable_path=`, never via `channel=`, so the variable is now
+  ignored by that check (it still resolves a Chrome binary everywhere else).
+
+### Security
+
+- **`httpx2` / `httpcore2` bumped to 2.12.0, clearing five newly published CVEs**
+  ([#766](https://github.com/ffroliva/gflow-cli/pull/766)). `httpcore2` CVE-2026-84381 and
+  `httpx2` CVE-2026-84378 / -84379 / -84380 / -84382, all against 2.9.1; both arrive
+  transitively through `mcp`. The advisories were published against an unchanged lockfile —
+  `Dependency audit (pip-audit)` went red on `develop` without any dependency change — so
+  this is not a regression introduced by a feature PR. `uvx pip-audit` on the exported
+  requirements now reports no known vulnerabilities. The bump also adds `httpx2-jsfetch`
+  1.0 to the lock, marked `sys_platform == 'emscripten'` (Pyodide/WASM only); it is never
+  installed on any platform gflow supports.
+
 ## [0.71.1] — 2026-09-08
 
 ### Fixed
@@ -4580,7 +4664,8 @@ shell-script template that branches on these codes.
 
 First skeleton. Not functional end-to-end yet.
 
-[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.71.1...HEAD
+[Unreleased]: https://github.com/ffroliva/gflow-cli/compare/v0.72.0...HEAD
+[0.72.0]: https://github.com/ffroliva/gflow-cli/compare/v0.71.1...v0.72.0
 [0.71.1]: https://github.com/ffroliva/gflow-cli/compare/v0.71.0...v0.71.1
 [0.71.0]: https://github.com/ffroliva/gflow-cli/compare/v0.70.0...v0.71.0
 [0.70.0]: https://github.com/ffroliva/gflow-cli/compare/v0.69.0...v0.70.0

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/KNOWN_ISSUES.md

@@ -14,13 +14,13 @@ Living list of behaviour that's broken, surprising, or limited by design — alo
 
 ## Open
 
-### Flow is migrating to `flow.google.com`; gflow drives the migrated frontend for t2v, i2v from a local start frame, and r2v from local reference files (rest of the matrix pending)
+### Flow is migrating to `flow.google.com`; generation coverage is partial but includes images
 
-- **Status:** Open (partially resolved) · **Severity:** High for everything except text-to-video, local-file image-to-video and local-file reference-to-video · **Affected:** on accounts the rollout has reached, `gflow video t2v`, `gflow video i2v --initial-frame <local file>` and `gflow video r2v --ref <local file>` now run on the migrated host (with `--project`); an end frame, a frame by UUID or `@Name`, references by `@Name` or `--reference-entity`, `image`, scenes, extend, instructions and tools are not ported yet and still exit 36. **`character` is NOT in that list any more** — `character create` was verified working on the migrated host in v0.70.0 and `character list` was re-verified there on 2026-09-07. This line claimed otherwise for a day, which is the dangerous direction for a stale doc to be stale in: a migrated user reading it concludes a working feature is impossible. Of the remainder, only the i2v-by-UUID case rests on a positive observation of absence (the Frames picker's tiles carry no media id); `scenes`, `extend`, `instructions` and `tools` have never had a probe run against them at all, so read them as *unported by gflow*, never as *impossible on the host*
+- **Status:** Open (partially resolved) · **Severity:** High for unported forms · **Affected:** on accounts the rollout has reached, `gflow video t2v`, local-file `video i2v` / `r2v`, `gflow image t2i`, and local-file `gflow image i2i` now run on the migrated host. Image mode supports Nano Banana 2 / Pro, the four aspect ratios its radiogroup was enumerated with (16:9, 4:3, 1:1, 9:16), and count 1–4; `3:4` had no radio in that enumeration and is refused before submit rather than reported as selector drift. Image refs by UUID, `@Name` / `--reference-entity`, Agent instructions, Imagen 4, video end frames, video refs by UUID/name, scenes, extend, instructions and tools are not ported yet and fail before submit. **`character` is NOT in that list any more** — `character create` and `character list` work on the migrated host. Of the remainder, only the i2v-by-UUID case rests on a positive observation of absence (the Frames picker tiles carry no media id); `scenes`, `extend`, `instructions` and `tools` remain *unported by gflow*, never proven impossible on the host.
 - **Tracked:** [#639](https://github.com/ffroliva/gflow-cli/issues/639) · Reported 2026-09-02 against 0.59.0, 0.62.1, 0.63.0 and 0.65.0
 - **Confirmed live 2026-09-03 on a second, independent account** (`ffroliva`) — see [LIVE_VERIFICATION_v0.66.0](docs/LIVE_VERIFICATION_v0.66.0.md). A read-only probe of the migrated origin measured `i_total: 0`, reproducing the reporter's central measurement.
 - **`--reference-entity` was refused on `r2v` but not on `t2v`** ([#716](https://github.com/ffroliva/gflow-cli/issues/716), fixed in v0.71.0): the "not ported, exit 36" refusal above sat inside the r2v branch of the routing gate, so a `t2v` request carrying a character entity returned from that gate without its entities ever being inspected — and nothing downstream attaches one on this host. The generation was **submitted and billed** with the entity silently dropped, returning a plausible clip of the wrong person. The check is now mode-independent and ahead of every early return. If you ran `gflow video t2v @Name …` or `--reference-entity` on a moved account before this fix, the identity in those clips was never bound.
-- **The migrated composer DOES have an image mode** ([#692](https://github.com/ffroliva/gflow-cli/issues/692)): a code comment claimed, as "measured, not assumed", that it has none. Falsified 2026-09-07 — its settings overlay carries a `mode` radiogroup of `[imageImage, videocamVideo]`, present and hit-testable. Nothing was clicked on that axis and nothing was submitted, so this does **not** establish that `image` works on a moved account; it establishes only that the claim it cannot is unfounded. Read the remaining exit 36 as *gflow does not drive this yet*, never as *the host cannot do it*; see [the spike](docs/superpowers/spikes/2026-09-07-migrated-composer-has-an-image-mode.md).
+- **The migrated composer image path is now driven** ([#692](https://github.com/ffroliva/gflow-cli/issues/692)): the first probe established a hit-testable Image mode; the 2026-09-08 follow-up captured real T2I and local-file I2I submissions on `ogiZ0b`, including page-owned reCAPTCHA, upload ids, response records and signed JPEG downloads. See [the submit-wire spike](docs/superpowers/spikes/2026-09-08-migrated-image-submit-wire.md).
 - **Image commands on a moved account** ([#673](https://github.com/ffroliva/gflow-cli/issues/673), fixed in v0.69.0): through v0.68.0 `image t2i` / `i2i` (and `upscale`, `extend`) died with exit 1 `RecaptchaError` within seconds, before any submit, instead of the exit 36 above, because the labs client minted the reCAPTCHA token on the `flow.google.com` project grid before any migration guard ran. The guard now runs at the mint. If you still see a `RecaptchaError` on a moved account right after `auth login`, that is the labs logged-out landing page from the [#644](https://github.com/ffroliva/gflow-cli/issues/644) cookie harvest, not this.
 
 Google is moving Flow off Labs onto its own origin. On a migrated page load,
@@ -48,7 +48,7 @@ This is **not** selector rot, not [#493](https://github.com/ffroliva/gflow-cli/i
 and not the agentic cohort — the agentic indicators are absent too. It is a
 different origin serving different markup.
 
-**What works now — text-to-video on the migrated host.** `gflow video t2v … --project <id>`
+**What works now — generation on the migrated host.** `gflow video t2v … --project <id>`
 drives the migrated editor directly (settings through its option groups, prompt,
 submit, then it observes the app's own `batchexecute` status replies and downloads
 the clip). Two real clips were generated this way on 2026-09-05 — spike
@@ -56,10 +56,11 @@ the clip). Two real clips were generated this way on 2026-09-05 — spike
 (`GFLOW_CLI_FLOW_HOST=auto`): flow.google.com is the **default** host for that
 command on every account — moved or not; `flow.google.com` forces it for
 everything, and `labs.google` switches the migrated composer off. Limits today: `--project` is required (project creation from the
-migrated editor is not ported), and only `t2v`, `i2v` from a local `--initial-frame` (no end frame,
+migrated editor is not ported), and `t2v`, `i2v` from a local `--initial-frame` (no end frame,
 no UUID/`@Name` frame — the migrated Frames picker exposes no media id in its DOM, so a frame is
 found by file name after gflow uploads it through the editor), and `r2v` from local `--ref` files
-(see the next paragraph) — everything else still exits 36.
+(see the next paragraph), plus `image t2i` and local-file `image i2i` — unsupported
+forms still exit 36.
 
 **`r2v` from local `--ref` files also runs there (2026-09-06).** Each file is uploaded
 through the same editor toolbar path i2v uses — so the app's own `maseQ` reply names the
@@ -73,6 +74,12 @@ References by `@Name` and character entities stay on labs, for the same reason a
 UUID does: the picker exposes no media id to anchor on. Capture:
 [2026-09-05-migrated-r2v-attach-surface](docs/superpowers/spikes/2026-09-05-migrated-r2v-attach-surface.md).
 
+**Images also run there (2026-09-08).** The driver selects Image mode, Nano Banana 2
+or Pro, any supported aspect and count 1–4, then observes the page's own synchronous
+`ogiZ0b` reply. Local I2I files use the existing `maseQ` upload and mention path; every
+uploaded id must appear in the submit body before the result is trusted. UUID/entity
+references, Agent instructions, and Imagen 4 remain pre-submit refusals on this host.
+
 **Models on the migrated host.** Its picker is driven for every tier the account's
 menu actually renders, `veo-lite-lp` included — matched by the `[Lower Priority]`
 tag alone, exactly as on labs.google. That entry was first captured on 2026-09-05
@@ -100,8 +107,9 @@ which Playwright updates in the same tick as the hand-off navigation — and fai
 with the distinct, non-retryable exit 36 instead of the misleading
 `UiSelectorDriftError` (exit 23, "file a selector bug"). `_check_logged_in` also
 accepts the migrated host, so a migrated load is no longer misread as a
-logged-out session. Text-to-video is driven (above); image, i2v/r2v, characters,
-scenes, extend, instructions, tools and project creation are the remaining work
+logged-out session. The generation forms listed above and characters are driven;
+scenes, extend, instructions, tools, project creation, and the named reference/model
+variants are the remaining work
 tracked here — no retry helps for those until each is ported.
 
 > **v0.66.1's fast-fail did not fire in the field, and v0.66.2 is the correction.**
@@ -1515,9 +1523,10 @@ End-to-end live-verified on the `ffroliva` profile across `9:16`, `16:9`, `1:1`,
 
 ### G12 "browser not secure" block — Google rejects automated sign-in
 
-- **Status:** Resolved · **Severity:** Critical (blocked `gflow auth login`) · **Fixed in:** v0.6.0a2
+- **Status:** Resolved · **Severity:** Critical (blocked `gflow auth login`) · **Fixed in:** v0.6.0a2 · **Mitigation reimplemented + re-measured:** 2026-09-08
 
-Google's sign-in flow (`accounts.google.com/v3/signin/rejected`) detected Playwright's bundled Chromium as an automated browser and refused the login with no user-facing error.
+Google's sign-in flow (`accounts.google.com/v3/signin/rejected`) rejects a browser that
+advertises itself as automated, and refuses the login with no user-facing error.
 
 **Root cause (timing race):** Without `--disable-blink-features=AutomationControlled`,
 Blink's C++ engine sets `navigator.webdriver = true` as a non-configurable, non-writable
@@ -1525,20 +1534,52 @@ native property at Chrome startup — before any JavaScript (including `add_init
 can run. The `Object.defineProperty` override silently fails. With the flag, the property
 is never set; the JS override then works as belt-and-suspenders.
 
-**Resolution:** `v0.6.0a2` adds `RealChromeStrategy` — a new auth strategy that launches
-the system's real Google Chrome via Playwright's `channel="chrome"` with stealth flags.
+**Resolution:** `gflow auth login` launches the system's real Google Chrome through
+Playwright's `channel="chrome"` with `chromium_sandbox=True`, `no_viewport=True`, and both
+stealth flags — `--disable-blink-features=AutomationControlled` and
+`ignore_default_args=["--enable-automation"]`. Because gflow owns that browser it also
+detects the completed Flow sign-in and closes the window itself; see
+[docs/AUTHENTICATION.md](docs/AUTHENTICATION.md). When no Chrome channel resolves, or
+Google rejects the browser anyway, login falls back automatically to launching Chrome as a
+plain subprocess and waiting for you to close the window. There is no flag and no choice to
+make, and closing the window yourself works on either path.
+
+> **This entry described that Playwright implementation long before it existed.**
+> It read *"`v0.6.0a2` adds `RealChromeStrategy` — launches the system's real Google Chrome
+> via Playwright's `channel="chrome"` with stealth flags."* `src/gflow_cli/auth/real_chrome.py`
+> was created at `eb0de133` (2026-07-19) as a bare `subprocess.Popen` passive capture, and
+> `git log -S'channel="chrome"' -- src/gflow_cli/auth/` returned **zero** commits until the
+> auto-close change. The paragraph above is the same shape restated deliberately as current
+> fact, not the same accident left standing.
 
 ```bash
-# Bypass G12 block explicitly:
+# Ask for real Chrome explicitly:
 gflow auth login --browser chrome
 
 # Or rely on auto-detection (default behaviour; picks real Chrome if installed):
 gflow auth login
 ```
 
-A cosmetic "You are using an unsupported command-line flag" notice may appear briefly in
-the Chrome window — this is harmless and can be dismissed. It is the accepted trade-off
-for bypassing G12.
+**The block is current Google behaviour — "Resolved" means the mitigation holds, not that
+Google stopped.** Re-measured 2026-09-08 across three throwaway *unauthenticated* profiles,
+each signed into by hand
+([spike](docs/superpowers/spikes/2026-09-08-g12-blocks-webdriver-not-playwright.md)): a
+browser advertising `navigator.webdriver === true` — real Chrome, no stealth flags — was
+rejected at `/v3/signin/rejected` **17.5 s** into the flow, while the same real Chrome
+*with* the flags reported `false`, never saw the rejection, and reached a Flow session
+cookie at 59.4 s. Playwright's bundled Chromium with the flags passed too, so the binary is
+not the discriminator; `navigator.webdriver` tracked the outcome in all three arms.
+
+> **This is N=1 — do not read it as a capability claim.** One account, one Windows host, one
+> residential IP, one Chrome build (`Chrome/149.0.0.0`), one day. Google's sign-in risk
+> scoring varies with account age and IP reputation, so it does not predict CI, a VPS, or a
+> fresh account. Every arm ran headed, so it says nothing about headless in either
+> direction. Sign-in is also a different gate from generation's reCAPTCHA Enterprise check;
+> a result on one does not move the other.
+
+The Chrome window no longer shows the "You are using an unsupported command-line flag"
+notice this entry used to warn about: that banner came from the `--no-sandbox` Playwright
+injects by default, and `chromium_sandbox=True` stops the injection.
 
 ---
 

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: gflow-cli
-Version: 0.71.1
+Version: 0.72.0
 Summary: Unofficial CLI for Google Flow — drive Veo image-to-video generations from the terminal.
 Project-URL: Homepage, https://github.com/ffroliva/gflow-cli
 Project-URL: Issues, https://github.com/ffroliva/gflow-cli/issues
@@ -130,7 +130,7 @@ gflow character create --project <id> --name "Aria" --face-prompt "..." --body-p
 
 Outputs land under `$GFLOW_CLI_OUTPUT_DIR`, or you can route them to S3, MinIO, or Google Cloud Storage with [`GFLOW_CLI_STORAGE_URI`](docs/EXTERNAL_STORAGE.md). The first call takes 30 to 90 seconds while Chromium warms up; later calls reuse the warm session.
 
-> **Why `--browser chrome`?** Google rejects Playwright's bundled Chromium. The CLI fails fast with a friendly error (`AuthBrowserRejectedError`, exit code 14) if you pick anything else.
+> **Why `--browser chrome`?** It is the only strategy that marks the profile as a real-Chrome profile, which is what later generation runs open it with. The default `auto` picks it whenever Chrome is installed — see [docs/AUTHENTICATION.md](docs/AUTHENTICATION.md).
 
 > **Installing from a local checkout?** `uv tool install <path>` **ignores `uv.lock`** and resolves dependencies from the `pyproject.toml` ranges, so it can hand you a Playwright build this project has never tested. Playwright ships the browser driver, and an untested minor can wedge a generation silently. Carry the locked version explicitly:
 >
@@ -198,7 +198,7 @@ gflow CLI  →  Provider (interchangeable)  →  Flow (ui_automation) / Mock (te
 
 **Current transport:** `ui_automation` drives Flow through a persistent Playwright Chromium profile. It is production-stable and verified end-to-end every release (see the per-release `LIVE_VERIFICATION_*` evidence files).
 
-**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). `flow.google.com` is the default host for what gflow has ported to it — text-to-video, image-to-video from a local start frame, and reference-to-video from local `--ref` files, today — on every account; the rest of the matrix keeps the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
+**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). The migrated driver covers text-to-video, image-to-video from a local start frame, reference-to-video from local files, text-to-image, and image-to-image from local files. Image generation supports Nano Banana 2 / Pro, the four aspect ratios measured on that host (16:9, 4:3, 1:1, 9:16), and counts 1–4; an existing project is required at the transport boundary. UUID/entity references, instructions, Imagen 4, and the rest of the matrix keep the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
 
 **What's blocked:** a pure HTTP transport for video generation. The video upload endpoint returns HTTP 401 under non-Chrome browsers plus a reCAPTCHA mint we cannot reproduce headlessly. Three earlier HTTP strategies (`evaluate_fetch`, `bearer`, `sapisidhash`) live under `src/gflow_cli/api/transports/experimental/` for research, off the production path.
 

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/README.md

@@ -59,7 +59,7 @@ gflow character create --project <id> --name "Aria" --face-prompt "..." --body-p
 
 Outputs land under `$GFLOW_CLI_OUTPUT_DIR`, or you can route them to S3, MinIO, or Google Cloud Storage with [`GFLOW_CLI_STORAGE_URI`](docs/EXTERNAL_STORAGE.md). The first call takes 30 to 90 seconds while Chromium warms up; later calls reuse the warm session.
 
-> **Why `--browser chrome`?** Google rejects Playwright's bundled Chromium. The CLI fails fast with a friendly error (`AuthBrowserRejectedError`, exit code 14) if you pick anything else.
+> **Why `--browser chrome`?** It is the only strategy that marks the profile as a real-Chrome profile, which is what later generation runs open it with. The default `auto` picks it whenever Chrome is installed — see [docs/AUTHENTICATION.md](docs/AUTHENTICATION.md).
 
 > **Installing from a local checkout?** `uv tool install <path>` **ignores `uv.lock`** and resolves dependencies from the `pyproject.toml` ranges, so it can hand you a Playwright build this project has never tested. Playwright ships the browser driver, and an untested minor can wedge a generation silently. Carry the locked version explicitly:
 >
@@ -127,7 +127,7 @@ gflow CLI  →  Provider (interchangeable)  →  Flow (ui_automation) / Mock (te
 
 **Current transport:** `ui_automation` drives Flow through a persistent Playwright Chromium profile. It is production-stable and verified end-to-end every release (see the per-release `LIVE_VERIFICATION_*` evidence files).
 
-**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). `flow.google.com` is the default host for what gflow has ported to it — text-to-video, image-to-video from a local start frame, and reference-to-video from local `--ref` files, today — on every account; the rest of the matrix keeps the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
+**Two Flow frontends:** Google is moving accounts from `labs.google` onto `flow.google.com` ([#639](https://github.com/ffroliva/gflow-cli/issues/639)) — same product, different widget toolkit and wire protocol (`batchexecute` instead of `aisandbox-pa`). The migrated driver covers text-to-video, image-to-video from a local start frame, reference-to-video from local files, text-to-image, and image-to-image from local files. Image generation supports Nano Banana 2 / Pro, the four aspect ratios measured on that host (16:9, 4:3, 1:1, 9:16), and counts 1–4; an existing project is required at the transport boundary. UUID/entity references, instructions, Imagen 4, and the rest of the matrix keep the labs driver until ported (`GFLOW_CLI_FLOW_HOST`, see [CONFIGURATION](docs/CONFIGURATION.md#gflow_cli_flow_host)).
 
 **What's blocked:** a pure HTTP transport for video generation. The video upload endpoint returns HTTP 401 under non-Chrome browsers plus a reCAPTCHA mint we cannot reproduce headlessly. Three earlier HTTP strategies (`evaluate_fetch`, `bearer`, `sapisidhash`) live under `src/gflow_cli/api/transports/experimental/` for research, off the production path.
 

{gflow_cli-0.71.1/website → gflow_cli-0.72.0}/docs/ARCHITECTURE.md

@@ -79,7 +79,7 @@ src/gflow_cli/auth/
 └── strategies.py        # (internal) shared Playwright helpers
 ```
 
-**Why:** Google's bot-detection ("G12 block") rejects Playwright's bundled Chromium during `gflow auth login`. Launching the user's installed Google Chrome with `--disable-blink-features=AutomationControlled` plus a JS `add_init_script` that overrides `navigator.webdriver` bypasses detection. Two strategies are needed because the setup (persistent-context flags, Chrome binary path, stealth init) differs fundamentally between them.
+**Why two strategies:** Google's "G12 block" keys on a browser that *advertises* automation (`navigator.webdriver`), not on which binary runs. Both strategies therefore build their launch options from the same `login_launch_kwargs()` helper — `--disable-blink-features=AutomationControlled` plus `ignore_default_args=["--enable-automation"]` — and differ only by `channel="chrome"`. They stay separate classes for what those options do not carry: `name` supplies the `source=` label on the session probe (a caller-supplied `"chrome"`/`"internal"` log value, never read back from a response), only the `chrome` strategy writes the `.gflow_browser_strategy` marker that `channel_for_profile()` reads later, and `factory.py` is a name→type registry that `--browser auto|chrome|internal` routes through.
 
 **AuthStrategy Protocol** (`base.py`):
 ```python
@@ -94,10 +94,10 @@ class AuthStrategy(Protocol):
 - `mode="internal"` — explicit `InternalChromiumStrategy`.
 
 **RealChromeStrategy stealth design** (`real_chrome.py`):
-- Uses a **Passive Capture** pattern: launches system Chrome via `subprocess.Popen` without any automation flags or remote-debugging ports.
-- Provides a 100% clean browser process that Google's G12 block cannot detect.
-- The CLI blocks on `proc.wait()`, prompting the user to complete the sign-in and **close the browser completely**.
-- Post-close: performs a fast, headless `launch_persistent_context` probe to verify the `SAPISID` cookie was successfully captured.
+- **Default — Playwright-owned Chrome.** Launches the system's real Google Chrome via Playwright's `channel="chrome"` with `chromium_sandbox=True`, `no_viewport=True`, `--disable-blink-features=AutomationControlled`, and `ignore_default_args=["--enable-automation"]`. What Google's G12 block keys on is a browser that *advertises* automation (`navigator.webdriver`), not the Playwright connection itself; with these flags the property is `false` and sign-in proceeds normally. See the G12 entry in [KNOWN_ISSUES.md](../KNOWN_ISSUES.md) for the 2026-09-08 measurement and its N=1 caveat.
+- Because gflow owns that context, it polls the Flow session endpoint from it until the outcome is `AUTHENTICATED` and then **closes the browser itself** — the user is not asked to close anything. A user who closes the window anyway is routed to the same `verify_flow_profile` check, never to an error.
+- **Automatic fallback — Passive Capture.** `login()` falls back on four conditions — a `headless=True` caller (the CLI exposes no such flag; this guards library callers), Playwright cannot resolve a Chrome channel (`browser_manager.is_playwright_chrome_channel_available()`), `launch_persistent_context` raises, or Google rejects the owned browser (`AuthBrowserRejectedError`, swallowed here rather than surfaced as exit 14) — and then silently falls back to the older shape: system Chrome via `subprocess.Popen` with no automation flags and no remote-debugging port, the CLI blocking on `proc.wait()` until the user closes the window. There is **no user-facing flag and no choice to make** — a Chromium-only host is never locked out of onboarding.
+- Verification: both paths end in the same `verify_flow_profile` call after the browser is gone. That probe is **httpx-first** — it reads the profile's cookie store directly via `browser_cookie3` and only falls back to a headless `launch_persistent_context` when cookie decryption fails (DPAPI on Windows, keychain on macOS, libsecret on Linux). The default path additionally polls the same session contract *from the browser it owns*, which is what tells it when to close. Both write the `.gflow_browser_strategy = "chrome"` marker that `channel_for_profile()` later reads.
 - Privacy guard: raises `SecurityError` if the resolved `profile_dir` is outside `GFLOW_CLI_HOME` — protects the user's primary system Chrome profile from being used as a session store.
 
 **UiAutomationTransport (UI Mimicry)**:
@@ -424,7 +424,7 @@ This is the project's defining trade-off and the most valuable place an external
 
 Google's auth + reCAPTCHA stack on `aisandbox-pa.googleapis.com` rejects:
 
-1. **Playwright's bundled Chromium** — flagged by Google's bot detection on first request. The CLI fails fast with `AuthBrowserRejectedError` (exit code 14) when this happens.
+1. **Browsers that advertise automation** — `navigator.webdriver = true` is what Google's bot detection flags, not the bundled binary itself; every launch path passes `--disable-blink-features=AutomationControlled` to keep it `false`. A sign-in that still lands on Google's rejection page raises `AuthBrowserRejectedError` (exit code 14) from the `internal` strategy; the `chrome` strategy retries on its no-automation subprocess path instead.
 2. **Headless browsers** — same fingerprinting trips during the OAuth-consent flow.
 3. **Bare HTTP clients** without the cookies + tokens minted by a real Chrome session — most endpoints return HTTP 401 or a reCAPTCHA challenge that can only be solved interactively.
 
@@ -436,7 +436,7 @@ We attempted three pure-HTTP transport strategies before settling on `ui_automat
 
 All three now live as standalone modules under `src/gflow_cli/api/transports/experimental/` (`evaluate_fetch.py` / `bearer.py` / `sapisidhash.py`), preserved for reference and future iteration. None survives Google's anti-bot stack for mutation/generation endpoints, so the production path is `ui_automation`.
 
-**The migrated `flow.google.com` host (#639, v0.67.0).** Google is moving accounts off `labs.google` onto `flow.google.com`, a rewritten frontend with a different widget toolkit and a `batchexecute` wire instead of `aisandbox-pa` REST. `src/gflow_cli/api/transports/migrated_composer.py` drives that editor for text-to-video, image-to-video from a local start frame, and reference-to-video from local `--ref` files (v0.70.0) — still through the same real-Chrome Playwright session — by operating the composer UI and then *observing* the app's own `batchexecute` replies (`YhhmEf`/`eb1hJf` submit, `jwpduf` status, `as29s` result) before downloading the clip. A start frame goes in through the editor's own Upload entry (the app's `maseQ` reply names the media id — `migrated.frame_uploaded`), is bound in the Frames picker by file name (`migrated.frame_bound`), and the submit *request* is inspected for that id and an i2v model key before the run is trusted (`WireFormatError` otherwise); a modal over a fresh editor is closed first (`migrated.dialog_dismissed`). `GFLOW_CLI_FLOW_HOST` routes between the two (`auto` = migrated host for every request it can serve, `--project` required there); the rest of the command matrix keeps `ui_automation` on unmoved accounts and exits 36 on moved ones. Recon: `docs/superpowers/spikes/2026-09-05-migrated-host-wire-protocol.md`.
+**The migrated `flow.google.com` host (#639, v0.67.0).** Google is moving accounts off `labs.google` onto `flow.google.com`, a rewritten frontend with a different widget toolkit and a `batchexecute` wire instead of `aisandbox-pa` REST. `src/gflow_cli/api/transports/migrated_composer.py` drives that editor for text-to-video, local-file image-to-video/reference-to-video, text-to-image, and local-file image-to-image — still through the same real-Chrome Playwright session — by operating the composer UI and then *observing* the app's own replies. Video uses `YhhmEf`/`eb1hJf`/`MZZa6b` submit plus `jwpduf`/`as29s` status/result; image uses synchronous `ogiZ0b` replies carrying signed JPEG URLs. Local files go through the editor's own `maseQ` upload and the resulting media ids are asserted in the outgoing submit body before the run is trusted (`WireFormatError` otherwise). The migrated page owns image reCAPTCHA minting; the client skips the labs token path so moved accounts no longer fail with `RecaptchaError` on the root grid. `GFLOW_CLI_FLOW_HOST` routes between the two (`auto` keeps migrated images on moved accounts and uses labs for them on unmoved accounts; `--project` is required on the migrated path); unsupported UUID/entity/instruction/Imagen-4 image forms still fail before submit. Recon: `docs/superpowers/spikes/2026-09-08-migrated-image-submit-wire.md`.
 
 **Standalone-only transports.** `bearer` and `sapisidhash` discard any caller-supplied Playwright page and launch their own browser under a fresh `ProfileLease`, so they are **standalone-only** — they cannot run inside a `FlowApiClient` that already holds the profile lease (the second acquire would self-lock with `ProfileLockedError`). Selecting either via `GFLOW_CLI_TRANSPORT` (or the Python API) while the client owns the profile now fails fast with a clear `ConfigurationError` naming the transport, rather than the opaque lock error. `evaluate_fetch` is exempt: it reuses the client's shared page and takes no second lease. The standalone-only set lives in `STANDALONE_ONLY_TRANSPORTS` (`api/transports/__init__.py`); to drive `bearer`/`sapisidhash`, run them outside an owning client.
 

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/docs/AUTHENTICATION.md

@@ -143,7 +143,7 @@ for you to sign in. The CLI automatically detects success and persists the sessi
 ```bash
 gflow auth login                   # default profile, auto browser
 gflow auth login --profile work    # named profile (creates if missing)
-gflow auth login --browser chrome  # force real Chrome (bypasses G12 block)
+gflow auth login --browser chrome  # force the chrome strategy (real Chrome + its profile marker)
 ```
 
 Re-running this command refreshes an expired session: it reuses the existing profile dir,
@@ -179,17 +179,37 @@ and the profile keeps the name `default`.
 | Value | Browser used | When to use |
 |---|---|---|
 | `auto` (default) | Real Chrome if installed; falls back to internal | First choice for most users |
-| `chrome` | System Google Chrome (**Passive Capture**) | Required to bypass "G12" blocks |
+| `chrome` | System Google Chrome, driven by Playwright (auto-closes) | Required for a chrome-strategy profile |
 | `internal` | Playwright's bundled Chromium | Fallback when Chrome isn't installed |
 
 Override with the env var: `GFLOW_CLI_AUTH_BROWSER=chrome gflow auth login`
 
-**Why `chrome` bypasses bot detection:** Playwright's default automation mode exposes
-`navigator.webdriver = true` as a non-configurable native property. Google detects this
-and redirects to `/v3/signin/rejected` (the "G12 block"). The `chrome` strategy
-implements **Passive Capture**: it launches your real system Chrome as a 100% standard
-process without any automation flags or debugging ports. You log in manually, close
-the window, and `gflow` extracts the verified session from the profile.
+`internal` now launches with the same anti-automation flags as `chrome` (it previously did
+not, which was the configuration Google rejects). It stays a fallback rather than a
+recommendation: a profile created by `internal` carries no `chrome` strategy marker, so
+generation later opens it with bundled Chromium instead of your real Chrome.
+
+**Why `chrome` bypasses bot detection:** what Google rejects is a browser that *advertises*
+automation. Blink sets `navigator.webdriver = true` as a non-configurable native property
+unless `--disable-blink-features=AutomationControlled` is passed, and Google redirects that
+browser to `/v3/signin/rejected` (the "G12 block"). The `chrome` strategy launches your real
+system Chrome through Playwright with that flag plus
+`ignore_default_args=["--enable-automation"]`, `chromium_sandbox=True`, and
+`no_viewport=True`, so `navigator.webdriver` is `false` and the sign-in proceeds normally.
+The block itself is still live — re-measured 2026-09-08; see the G12 entry in
+[KNOWN_ISSUES.md](../KNOWN_ISSUES.md) for the numbers and their N=1 caveat.
+
+**You don't close the browser — gflow does.** Because gflow owns that Chrome window, it
+watches for the completed Flow sign-in and closes the window itself, then prints the
+verified account. If you close the window yourself it still works: gflow verifies the
+profile exactly the same way and does not treat a manual close as an error.
+
+**Automatic fallback, with nothing to choose.** If Playwright can't resolve a Chrome channel
+on this machine (a Chromium-only Linux box, for instance), or Google rejects the browser
+anyway, `gflow auth login` falls back to the earlier **Passive Capture** flow: Chrome
+launched as a plain process with no automation flags and no debugging port, where you close
+the window once the Flow editor has loaded and `gflow` extracts the verified session from the
+profile. There is no flag and no prompt for this — the fallback simply happens.
 
 **Privacy guard:** The `chrome` strategy strictly refuses to use any profile directory
 outside `GFLOW_CLI_HOME`. This protects your primary system Chrome profile from

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/docs/CHARACTER_RECON.md

@@ -207,7 +207,9 @@ With both fixed, the deep-linked editor binds reliably. See
 - `gflow character rm <id>` → entity delete (capture verb later).
 - Reuse: **`--character <id>` (repeatable → multi-reference)** on `gflow video` → adds
   `referenceEntities:[{entityId}]` to `video:batchAsyncGenerateVideoReferenceImages` (R2V mode, async + poll).
-  Same flag on `gflow image` pending an image-path confirm.
+  Same flag on `gflow image` remains pending on the migrated host: local-file image
+  generation is confirmed, but character/entity binding is intentionally refused until
+  its migrated picker wire is captured.
 
 ## Reuse from PR #123 (kittinan)
 

{gflow_cli-0.71.1 → gflow_cli-0.72.0}/docs/CONFIGURATION.md

@@ -361,11 +361,11 @@ GFLOW_CLI_HISTORY_PROMPTS=redacted gflow image t2i "confidential brief"
 
 **What:** Which Flow frontend gflow drives. Google is moving accounts from `labs.google/fx/tools/flow` onto `flow.google.com` one at a time ([#639](https://github.com/ffroliva/gflow-cli/issues/639)); the two are the same product on different widget toolkits and different wire protocols, so each has its own driver.
 **Values:**
-- `auto` (default) — **`flow.google.com` is the default host for every request it can serve today** (`video t2v`, `video i2v` from a local `--initial-frame` with no end frame, and `video r2v` from local `--ref` files — all with `--project`), on moved and unmoved accounts alike — the new host serves both. A request the new host cannot serve yet keeps the labs driver on an unmoved account; a moved account has no labs to fall back to: other modes exit 36, a missing `--project` or a labs-only model exit 11.
+- `auto` (default) — **`flow.google.com` is the default host for every video request it can serve today** (`video t2v`, local-file `video i2v` and `video r2v`, all with `--project`) on moved and unmoved accounts. Image requests stay on labs for an unmoved account, while a moved account uses the migrated composer for `image t2i` and local-file `image i2i`. A request the new host cannot serve keeps the labs driver on an unmoved account; a moved account has no labs fallback and unsupported forms exit 36/11 before submit.
 - `flow.google.com` — force the migrated composer for everything, including what it cannot serve yet (those requests then exit 36/11 instead of falling back).
 - `labs.google` — never use the migrated composer; a moved account fails with exit 36 (kill switch).
 **Default:** `auto`
-**Scope today:** the migrated composer covers `gflow video t2v`, `gflow video i2v --initial-frame <local file>` and `gflow video r2v --ref <local file>`, each with `--project <id>` (settings via the option groups, model picker, local files uploaded through the editor's own Upload entry — bound in the Frames picker by file name for i2v, attached as `@` mentions in the prompt for r2v — submit, status observed on the page's own `batchexecute` replies, download from the signed CDN URL). An end frame, a frame given by UUID or `@Name`, references given by `@Name` or `--reference-entity`, image, characters, scenes, extend, instructions and tools are not ported yet and exit 36 on a moved account. MCP inherits the setting from the server/daemon environment, not per call.
+**Scope today:** the migrated composer covers `gflow video t2v`, local-file `video i2v` / `r2v`, `gflow image t2i`, and local-file `gflow image i2i`. Images support Nano Banana 2 / Pro, the four aspect ratios enumerated on that host (16:9, 4:3, 1:1, 9:16 — `3:4` was not present and is refused before submit) and count 1–4; the page owns the `ogiZ0b` reCAPTCHA + submit and the response already contains completed signed image URLs. An end frame, UUID/name references, character entities, Agent instructions, Imagen 4, scenes, extend, instructions and tools are not ported yet and fail before submit on a moved account. MCP uses the same image service and queue payload, and inherits this setting from the server/daemon environment rather than per call.
 
 ### `GFLOW_CLI_PREFER_CLASSIC` *(deprecated — use `GFLOW_CLI_UI_MODE=classic`)*
 

{gflow_cli-0.71.1/website → gflow_cli-0.72.0}/docs/DEBUGGING.md

@@ -13,7 +13,7 @@
 | `gflow image t2i` hangs ≥ 3 min then fails with `TimeoutError` | Re-run with `--verbose` and grep for `batch_response_seen` | [Listener log keys](#listener--http-layer-debugging) |
 | `aspect_ratio_set_failed` warning then wrong-aspect output | The aspect-tab selector cascade missed; capture a DOM snapshot of the gen-settings panel | [Inspecting Flow's live UI](#inspecting-flows-live-ui) |
 | `UnicodeEncodeError: 'charmap' codec can't encode` on Windows | Set `PYTHONUTF8=1` (PowerShell: `$env:PYTHONUTF8="1"`) before any `gflow` invocation | [Windows console](#windows-console-encoding) |
-| `AuthBrowserRejectedError` / exit 14 | Re-login with `--browser chrome` | [`AUTHENTICATION.md`](AUTHENTICATION.md), `/gflow:known-issues` |
+| `AuthBrowserRejectedError` / exit 14 | Re-run `gflow auth login` (the `chrome` strategy retries automatically) | [`AUTHENTICATION.md`](AUTHENTICATION.md), `/gflow:known-issues` |
 | `BrowserSessionClosedError` / exit 15 in a long-lived worker | Recreate the `FlowApiClient` via its async context manager | [Lifecycle errors](#lifecycle--browser-state) |
 | Test suite OOMs / sandbox crashes | Run dirs separately (`tests/api`, `tests/auth tests/cli`, `tests/features`, then the rest with `--ignore`) | [Test suite memory](#test-suite-memory) |
 | New Flow UI label breaks a selector | Add a candidate to `_ASPECT_TAB_CANDIDATES` (or the relevant cascade) and live-verify | [Selector cascades](#selector-cascades) |
@@ -224,7 +224,7 @@ First visible-and-clickable wins. Log:
 |---|---|---|---|
 | `BrowserSessionClosedError` | 15 | Playwright page/context/browser was closed mid-call (translated from `TargetClosedError`) | Recreate `FlowApiClient` via `async with` |
 | `AuthExpiredError` | 3 | Session cookies no longer valid | `gflow auth login --profile <name>` |
-| `AuthBrowserRejectedError` | 14 | Google rejected Playwright's bundled Chromium | Re-login with `--browser chrome` |
+| `AuthBrowserRejectedError` | 14 | Google's sign-in rejected the browser for advertising automation; only the `internal` strategy surfaces it | Re-run `gflow auth login` (default `auto` picks the `chrome` strategy, which retries on a no-automation path) |
 | `AuthLoginTimeoutError` | 12 | User did not finish the OAuth flow in time | Run `gflow auth login` again; raise `GFLOW_CLI_AUTH_LOGIN_TIMEOUT` |
 | `TransportTimeoutError` | 9 | A single API call exceeded its timeout | Retry; check Flow status |
 | `WafRejectionError` | 10 | reCAPTCHA / WAF blocked the request | Wait + retry; verify session is healthy |
@@ -317,8 +317,9 @@ remediations. The most-hit categories:
   ([selector-cascades](#selector-cascades))
 - **Session expiry on a long-running worker** → use `health_check()`
   + recreate on `BrowserSessionClosedError`
-- **reCAPTCHA score too low** → must use real Chrome
-  (`--browser chrome`); never Playwright's bundled Chromium
+- **reCAPTCHA score too low** (generation, *not* sign-in) → must use real Chrome
+  (`--browser chrome`). Sign-in is a separate question: the 2026-09-08 spike measured
+  `navigator.webdriver`, not the binary, as what Google's sign-in rejects.
 
 ## See also