[HIGH PRIORITY][WARNING] Persistent "unusual activity" account block after FlowKit testing (manual Flow UI blocked)

High-priority warning

This appears more severe than #58 / #63.

Those issues described PUBLIC_ERROR_UNUSUAL_ACTIVITY in FlowKit while manual generation in Flow still worked. I now have 2 separate Google accounts where manual generation in Flow itself is blocked with:

Failed
We noticed some unusual activity. Please visit the Help Center for more information.
You have not been charged for this generation.

Account 1

Used with FlowKit on a server.
Entered this blocked state.
Manual Flow generation no longer works.

Account 2

Separate account, working normally on my local PC yesterday.
Today I used it while testing the FlowKit extension and trying to diagnose/fix this problem.
It then entered the same blocked state.
It remains blocked even when I return to the normal Flow UI from my home/residential IP.
I can no longer generate manually with this account either.

Why this is important

This is different from #58 / #63: there, FlowKit failed but the account still worked in Flow's UI. Here the Flow UI itself is now blocked after extension testing.

I cannot prove FlowKit alone caused the restriction, so this is correlation, not confirmed causation. But the second account was working immediately before this testing and became blocked during it.

PR #64 recently changed the extension path around extension_hijack_detected, Trusted Types CSP and grecaptcha.enterprise.execute. I am not claiming #64 is definitely the cause, but this path should be reviewed carefully before more users test it on valuable accounts.

Requested action

Please treat this as a high-priority account-safety/regression issue:

add a prominent temporary warning to README/release notes/extension docs;
recommend disposable/test accounts until the root cause is understood;
fail closed on persistent PUBLIC_ERROR_UNUSUAL_ACTIVITY / hijack signals instead of continuing retries/token minting;
audit the current captcha/hijack-bypass path for behavior that may accumulate risk signals;
distinguish extension-only failure vs manual Flow UI also blocked in logs;
document any known cooldown/recovery process;
consider disabling the risky generation path by default until understood.

For me this has already made two accounts unusable for manual Flow generation, so it should be visible as a warning to current testers.

clear cookie or change your IP

That does not address the issue.

As described above, I already returned the affected account to the normal Flow UI from my home/residential IP, and the account remained blocked. The restriction is not limited to the server IP or FlowKit session.

Two separate accounts reached the same state after FlowKit testing, where manual Flow generation itself stopped working.

If clearing cookies is expected to resolve this specific account-level state, please explain why and what cookies/state should be cleared. Otherwise, please reopen this — the main account-safety concern described in the issue remains unresolved.

@crisng95

A data point from another account (Google AI Ultra, Windows), in case it helps narrow this down.

We ran FlowKit (extension + agent) every day until 2026-09-22, when every captcha-gated submit started returning PUBLIC_ERROR_UNUSUAL_ACTIVITY (timeline in Every captcha-gated RPC returns PUBLIC_ERROR_UNUSUAL_ACTIVITY since the Flow frontend build of 2026-09-22, while the UI itself still works #58). After that we sent only one single test submit per day on 09-26, 09-27 and 09-28. All three were refused. We stopped FlowKit completely on 09-28 after reading this issue.
Our local checkout does not include fix(extension): mint reCAPTCHA via hidden widget — unblocks generate after the 2026-09-22 build #62 or feat: bypass extension_hijack_detected + Trusted Types CSP #64, so this account never ran the reCAPTCHA hidden-widget mint or the extension_hijack_detected bypass.
As of 2026-10-10, the same account still generates normally in the manual Flow UI. It did not reach the account-level state described here.
Separately, browser automation of that account with another tool (gflow-cli, headed system Chrome, separate profiles, no FlowKit extension) is currently refused with the same error on two browser profiles. Details in Migrated host: Flow refuses Playwright submits with 'unusual activity' card — manual Chrome on the same profile works ffroliva/gflow-cli#906.

This proves nothing on its own. It does suggest the account-level block reported here is not an automatic consequence of the first UNUSUAL_ACTIVITY refusals. Whatever pushed these two accounts further may be in what happened after those refusals: retries, repeated mints, or the hijack bypass. That is what the safety holds in #68 address.

@crisng95, would you consider merging #68, or an equivalent persistent hold, before more users reach this state? We can share exact timestamps if useful.

One important clarification regarding my original report:

This is not a complete Google account ban. The restriction specifically affects manual generation in the Google Flow UI.

I cannot manually generate images or videos in Flow, even when accessing the account from my own computer using my residential IP.
Surprisingly, generation through Flow's built-in agent still works on the same account.
The manual generation restriction has persisted for several days without resolving.

So the account itself remains functional, but manual Flow generation is consistently refused.

This distinction may be important for identifying what exactly Google's unusual-activity protection is blocking.

fix(flow): keep the unusual-activity hold across restarts, bound hija…

Navigation Menu

Repository navigation

[HIGH PRIORITY][WARNING] Persistent "unusual activity" account block after FlowKit testing (manual Flow UI blocked) #67