⏻
HELGE SVERREAll-stack Developer
Bergen, Norway • v13.0
est. 2012  |  197 repos  |  12.8k+ contributions
Tools  |   Theme:
Force-Enabling Chrome Skills From an Unsupported Region
September 12, 2026

Google shipped Skills in Chrome earlier this year. Saved prompts you can run against whatever page you're on. I wanted one thing out of it: point it at my work inbox and get a TL;DR. That is the entire pitch I needed.

Instead, chrome://skills/ gave me this:

Skills aren't available
To use Skills, sign in to Chrome with a Google Account that has Gemini in Chrome enabled

I am signed in. I've used Gemini plenty. What I don't have is a supported region. I live in Norway, and Norway is not on Google's availability list. Neither is most of the EU. Thanks, Europe.

This is how I got around it, and why it wasn't worth the trouble.

The obvious suspect: Google's account index

I have three Google accounts signed into one Chrome profile. My personal Gmail, plus two Workspace accounts. If you've ever juggled multiple Google accounts you know the pain. Google identifies them by position, not email: u/0, u/1, u/2, or a ?authuser=1 query param.

And plenty of Google properties refuse to let you switch account from their own UI.

Play Console is the worst offender. You open the developer console and if your developer account isn't the one Google decided is active, you're stuck behind a wall with no switcher. So you start editing the URL and guessing numbers: u/1, u/2, u/3. Analytics does the same thing with ?authuser=. You end up saving URLs to yourself with the magic index baked in because that's the only way to reach the right dashboard.

So my first theory was that Skills was failing the same way. Chrome grabs the primary account, that account isn't eligible, everything falls over. It fit perfectly.

It was completely wrong.

The account does matter downstream. Gemini in Chrome wants a personal account rather than a Workspace one, and it checks account capabilities. But none of that was the error on screen.

Side quest: "Your browser is managed by your organisation"

While digging through Chrome's config I noticed it was also claiming my browser was managed by an organisation. Personal Mac, personal account, no MDM, no configuration profiles. That one was too weird to leave alone.

The cause was a single stray policy key:

~/Library/Preferences/com.google.Chrome.plist
  MetricsReportingEnabled => false

On macOS, Chrome reads the com.google.Chrome defaults domain as a policy source. And Chrome shows the "managed by your organisation" banner for any policy, even one you set yourself. I had set that key ages ago, almost certainly from a tip about turning off telemetry reporting.

# Quit Chrome first
defaults delete com.google.Chrome MetricsReportingEnabled

Banner gone. I confirmed there were no configuration profiles, no /Library/Managed Preferences files, and that the profile itself reported is_managed = 0. Nothing was managing anything. It was just a policy key I'd shot into my own foot.

One mystery solved. Skills still didn't work.

The actual blocker: the country

Chrome keeps a Local State file next to your profile. On macOS:

~/Library/Application Support/Google/Chrome/Local State

Mine said this:

is_glic_eligible = false
variations_country = "no"
variations_permanent_consistency_country = ["153.0.8010.37", "no"]

no is Norway. variations_country is what Chrome's Variations service uses for regional feature gating, and Gemini in Chrome is gated hard by region.

Internally the Gemini sidebar is Project Glic. Skills is a layer on top of Glic. No Glic, no Skills. The Skills page doesn't even check its own flag for this, it asks Glic whether it's ready:

source->AddBoolean("isGlicEnabled",
                   glic::GlicEnabling::IsReadyForProfile(profile));

That's straight out of Chromium's skills_ui.cc. So the #skills flag that Google's own help page tells you to enable? It's for the staged rollout within supported regions. Against a country block it does nothing. I'd already enabled it. Nothing happened.

Reading the source for the real switch

The eligibility logic lives in chrome/browser/glic/public/glic_enabling.cc. If you read GetProfileReadyState, the order of checks matters:

  1. an admin kill switch
  2. sign-in state
  3. account capabilities (server-provided)
  4. the country filter
  5. the rollout state

And the very first thing it does is this:

if (command_line->HasSwitch(::switches::kGlicAutomation)) {
  return mojom::ProfileReadyState::kReady;
}

One switch, checked before anything else, returns "ready" unconditionally. Meanwhile the country check routes through EvaluateCountryEnablement, which bails out early:

if (!base::FeatureList::IsEnabled(features::kGlicCountryFiltering)) {
  return true;
}

Disable that feature and countries stop being filtered at all. There's a --glic-dev switch too, which skips the rollout check.

The flags were right there in the binary the whole time.

What worked

First, enable the base features in chrome://flags: #glic and #skills. Relaunch.

Then quit Chrome completely and start it with the switches:

open -a "Google Chrome" --args \
  --glic-automation \
  --glic-dev \
  --disable-features=GlicCountryFiltering,GlicLocaleFiltering

--glic-automation is the one doing the heavy lifting. It short-circuits every eligibility check before Chrome ever looks at my country. The rest is belt and suspenders.

That did it. chrome://skills/browse loaded, with the built-in skill library and the whole thing.

Caveats, because there always are. The switches only apply to that launch, so it's gone next time you start Chrome normally. --glic-automation is a test switch, not a supported feature. And the UI appearing doesn't mean the backend will actually serve you, since the account capability is still decided server-side. It worked for me, but don't build a workflow on it.

It works. It's bad.

Here's the part that annoyed me.

The entire reason I wanted Skills was email. My work inbox is a firehose and a "summarise this thread" button sounds like a gift. So I opened a long Gmail thread, opened Gemini, and tried to share the tab with it.

It wouldn't share. Gmail isn't one of the pages it will read.

Fine, I'll paste the text in instead. You can't paste into the Skills prompt either.

So the one thing I wanted, feed it an email and get a summary, is the one thing it refuses to do. It's built to read the current page and run a saved prompt against it, and on Gmail it just doesn't. Pasted text is off the table. The feature is a saved-prompt button with a narrow idea of which pages count.

Verdict

If you live in a supported region and you actually want "run this prompt on the current page", sure, go for it. It's fine.

If you're outside the rollout, the unlock works, but you're not missing much. And if your plan was summarising email, save yourself the afternoon. I fought a country block, an MDM ghost that wasn't real, and Google's account-index maze, and got a button that can't read my inbox.

Gemini, once again, was shit.




<!-- generated with nested tables and zero regrets -->