Modern Web Guidance: I Tested Google's Free Skill in Codex

I gave Codex Google's free Modern Web Guidance skill and watched its choices change. Both plain runs scored 2 of 10 on my prewritten checklist of built-in browser features; both guided runs scored 9 of 10. All four pages passed every interaction check. The surprise was in the files: the guided JavaScript was longer. The growing text box shows why browser features and backup code can arrive together.

What Google shipped

Chrome announced stable Modern Web Guidance on November 10, 2026, following its May preview. It is free, open-source software, stewarded by Chrome, Microsoft Edge, Mozilla Firefox, MDN and the web community. Software uses Apache 2.0; guide documentation has separate attribution terms.

Google says the release contains 203 use-case guides covering 250 web platform features. The agent gets instructions plus a searchable guide library. It searches for a job, retrieves guidance, and gets browser-support information and pitfalls alongside implementation patterns. Guide search runs locally with an offline embedding model and BM25, without API keys. Usage collection is a separate consideration.

Google's numbers

Google reports these November 8 evaluation results:

Agent and model	Google's reported pass rate	Tasks / assertions
Codex CLI, gpt-6.1-sol	54% → 82%	215 / 1,795
Claude Code, opus-5-5	57% → 88%	215 / 1,801
Antigravity CLI, gemini-4-argon	58% → 94%	214 / 1,673

Google's graders inspect source patterns, computed styles, runtime behavior and accessibility states. These are Google's self-reported evaluations. Their pass rates belong to that evaluation setup; my checklist below measures selected browser-feature choices in a separate experiment.

Google also says MetaMask's review bot reviewed about 480 pull requests over five weeks and prompted 43 fixes. I read those reports as reasons to inspect a trial in my own project.

My test

I asked GPT-6.1 Sol in Codex, at medium reasoning, to build Jotter: an account-settings page for a made-up notes app. The request included a profile dialog, growing bio, errors after interaction, expanding FAQ answers, a tooltip, theme controls and a saved message. The output used plain HTML, CSS and JavaScript, with no framework, external assets or network.

Run	Built-in feature checks of 10	Click-through of 10	Legacy-scan findings	app.js non-blank lines
plain-1	2	10	1	156
plain-2	2	10	1	165
guided-1	9	10	0	202
guided-2	9	10	0	271

The page request was identical. Guided runs also received the skill files, an instruction to read them, and a local search launcher because the sandbox had no internet. We used the same guides and search locally, with telemetry disabled. We did not test the marketplace installation.

I wrote the browser-feature checklist before the builds. Plain pages earned checks for native dialog and reduced-motion support. Guided pages selected additional browser features for the growing field, delayed validation, FAQ and tooltip. Neither guided page used light-dark().

Every page worked in the headless-Chrome click-through: opening and dismissing the dialog, rejecting invalid input, saving, expanding a question and focusing the tooltip. This is a small sample: one prompt, one model, two runs per condition. The scores describe the selected implementation patterns. They establish little about other projects or repeated performance.

Why the code got longer

Here is the actual resizing function from lab/runs/plain-1/app.js:

function growBio() {
  bioField.style.height = 'auto';
  bioField.style.height = `${bioField.scrollHeight + 2}px`;
}

It resets the height, measures the contents, and writes a height back. In lab/runs/guided-1/styles.css, the browser receives this rule:

textarea { field-sizing: content; block-size: auto; min-block-size: 6rem; max-block-size: 16rem; resize: vertical; }

The guided app.js still contains this function:

  function growBio() {
    if (CSS.supports('field-sizing', 'content')) return;
    bio.style.height = 'auto';
    bio.style.height = `${bio.scrollHeight + 2}px`;
  }

The support check skips measuring when the browser supports field-sizing. Otherwise, the helper supplies the required growing behavior. Both implementation paths remain in the output.

The skill defaults to Baseline Widely available and requires guide-recommended fallbacks for newer features unless you specify another support policy. The bundled field-sizing guide calls for feature detection and a workaround when older browsers must support growing fields. Our prompt required that behavior.

The dialog tells a similar story: guided-1 uses closedby="any", with a JavaScript handler when closedBy is absent. Its FAQ uses details and summary; plain-1 toggles classes from buttons. The guided tooltip also keeps manual interaction handling behind support checks.

Both guided pages added several such backup paths. The plain pages had none switched on by browser-support checks. These choices help explain the growth, though we have not accounted for every added line.

The catch

Telemetry is enabled by default. The README lists installation counts, calling agent names, retrieved guide IDs and agent-generated search queries; raw user prompts are excluded. Search phrases can still describe the work. Set DISABLE_TELEMETRY=1 before using the tool if you want to opt out.

Google says legacy-scan covers roughly 20% of guides with deterministic rules. It scans locally with no model calls. Each plain page received a textarea-resizing finding; each guided page received none. The rule drops matches guarded by a field-sizing feature query, explaining why the guided measuring helper can coexist with a clean scan.

Google's evaluations remain self-reported, and my sample remains small. Our click-through tested Chrome only. Safari and Firefox backup behavior still needs checking. A support policy helps select code; browser testing supplies evidence about its behavior.

How you can use this — my opinion

I would start with a small real component and save the current version for a diff. Decide on telemetry first. In the shell used to launch your agent:

export DISABLE_TELEMETRY=1

The documented Codex installation is:

codex plugin marketplace add GoogleChrome/modern-web-guidance
codex plugin add modern-web-guidance@googlechrome

For Claude Code, its documented commands are:

/plugin marketplace add GoogleChrome/modern-web-guidance
/plugin install modern-web-guidance@googlechrome
/reload-plugins

Before building, give the agent a browser target in AGENTS.md. This is my example policy:

We support the last two versions of Chrome, Edge, Firefox and Safari.

Ask the agent to explain each selected feature, its support check and its backup beside the diff. For the growing field, ask whether your supported versions need the measuring helper. On an existing project, use the scan, verify, report and modernize workflow to find candidates, then inspect whether an apparent older pattern is an intentional fallback.

Finally, exercise the dialog, errors, field and tooltip in the browsers you support, including those expected to activate backups. Share your experience in the free community.