AI Tools
How to Build a Chrome Extension With Claude Code
How to build a Chrome extension with Claude Code: the Manifest V3 pieces it needs to generate, the One-Click Rule for judging a first build, and what actually breaks the first time you load it into Chrome.
AI Educator, AI Tools and Training Club · August 28, 2026 · 9 min read
The short version
- You can build a working Chrome extension with Claude Code without hiring a developer - it writes the manifest.json, the popup, and the background service worker, and you load it into Chrome yourself through chrome://extensions in developer mode with no Chrome Web Store submission required to test it.
- Every Chrome extension now has to ship as Manifest V3 - the Chrome Web Store no longer accepts Manifest V2 submissions, and telling Claude Code that up front avoids a rebuild if it defaults to older patterns it may have seen in training data.
- Judge a first build against the One-Click Rule: it's working the moment the one action you built - the click, the capture, the lookup - does its job reliably in your own browser, not when every panel and setting you imagined exists.
The short answer
Yes, you can build a real Chrome extension with Claude Code without a developer on staff. You describe the one thing the extension should do, Claude Code generates the manifest.json, the popup interface, and the background service worker Manifest V3 requires, and you load the unpacked folder straight into Chrome through developer mode to test it on your own browser - no Chrome Web Store review needed until you're ready to publish. Building the extension and publishing it to the store are two separate steps, and this post covers both.
Why I built one instead of scoping a dev ticket
A client kept asking their team to manually copy data out of a web tool that had no export button and no API - the same five-minute task, several times a day, across a small team. Writing that up as a scoped project for a developer felt like overkill for something this narrow, and I wasn't sure the fix was even worth automating until someone actually used it for a week.
So I asked Claude Code to build the smallest version instead: one button in the browser toolbar, one action, pull the data off the current page and format it the way the team already used it. Not a polished product, a real test of whether removing five minutes of copy-paste, several times a day, actually mattered once it existed. [How to build an internal tool with Claude Code instead of buying software](/blog/how-to-build-an-internal-tool-with-claude-code-instead-of-buying-software) covers the same instinct applied to a full internal tool - the extension version is the same logic scoped down to a single browser action.
What a Chrome extension actually needs, specifically
A Chrome extension is a small, predictable set of files, and Claude Code knows the shape of all of them. Naming Manifest V3 specifically when you start matters, because the Chrome Web Store no longer accepts Manifest V2 submissions - it's the only option for anything you plan to publish, and it changes how the background logic is structured compared to older tutorials still floating around online.
| Piece | What it does | Why it matters for a first build |
|---|---|---|
| manifest.json | Declares the extension's name, permissions, and which files run where | Manifest V3 is required - the Chrome Web Store rejects V2 submissions |
| Service worker | Runs background logic in short bursts instead of staying open constantly | Replaces the old persistent background page V2 extensions relied on |
| Popup | The small window that opens when you click the extension's toolbar icon | The most common way a user actually triggers the extension's one action |
| Content script | Code that runs inside the page you're viewing, when the extension needs to read or change it | Needs its own explicit permission - Claude Code declares it in the manifest, it doesn't run automatically |
The pieces Claude Code generates
How I built it
- Wrote down the single action the extension had to perform, in one sentence, before opening Claude Code. Everything that wasn't that one action got cut from the first version.
- Described the extension to Claude Code in plain language and asked for a Manifest V3 build, naming the specific Chrome APIs it would need to read the page and store the result.
- Opened chrome://extensions, turned on Developer mode, and used 'Load unpacked' to point Chrome at the folder Claude Code generated - no build step, no store submission, working in the actual browser in under a minute.
- Clicked the toolbar icon on the real page the team used every day and ran the one action for real, instead of testing it against a mock page.
- Went back to Claude Code with the specific thing that didn't work - a field that didn't capture, a format that didn't match - and fixed one issue at a time rather than listing every improvement up front.
What broke, and what actually goes into publishing
My first version worked fine loaded unpacked and then silently failed to read the page the first time I tested it fresh - a content script permission I hadn't declared for that specific site. Manifest V3's permission model is stricter than what a lot of older tutorials show, and it's the single most common thing that works locally in one context and fails in another until the manifest names exactly what it needs.
Publishing to the Chrome Web Store is a separate, later step. It requires a one-time developer registration fee, and every submission goes through Google's review before it's publicly listed - review time varies and Google can reject a submission that asks for broader permissions than the extension's actual behavior justifies. None of that review applies while you're testing an unpacked extension in your own browser, which is why building and publishing are worth treating as two different jobs from the start.
The One-Click Rule, and when a real extension developer wins
Judge a first Chrome extension against the One-Click Rule: it's working the moment the one action you built does its job reliably, on the real page, in your own browser - not when every settings panel and edge case you imagined exists. A one-button extension that reliably does the one thing beats a feature-heavy one where half the options quietly don't work.
The honest limit is real too. If the extension needs to work across dozens of different site layouts, handle a login flow securely, or sync data across devices in real time, that's a genuinely harder build than a Claude Code first pass is meant to cover, and a developer who's shipped extensions before is worth paying for at that point. This workflow is for a narrow, well-defined browser action - not a replacement for a real extension developer once the scope grows past that.
How I coach members through this build
When a member describes a repetitive browser task, I ask whether it's genuinely one action repeated often, or a bigger workflow wearing a Chrome extension's clothes. The ones that fit are narrow: pull this data, fill this field, flag this condition, every time you're on this specific page. The ones that don't fit usually turn out to be a full internal tool that happens to start in the browser, which is a different build entirely.
[How to automate your business with n8n](/blog/how-to-automate-your-business-with-n8n) is worth a look before you build the extension version of a task - if the data you need is already reachable through an API, a scheduled automation might replace the manual click entirely without needing a browser extension at all.
Frequently asked questions
Do I need to know how to code to build a Chrome extension with Claude Code?
No. You describe the one action the extension should perform in plain language, and Claude Code writes the manifest.json, popup, and service worker. You test the result yourself by loading it unpacked into Chrome and clicking the toolbar icon on a real page.
Does my extension need to use Manifest V3?
Yes. The Chrome Web Store no longer accepts Manifest V2 submissions, so Manifest V3 is the only option for anything you plan to publish. Naming it explicitly when you start avoids a rebuild if Claude Code's first draft leans on older patterns.
Can I test my extension without publishing it to the Chrome Web Store?
Yes. Turn on Developer mode at chrome://extensions and use 'Load unpacked' to point Chrome at the folder Claude Code generates. It runs in your real browser immediately, with no store submission or review required to test it.
What does publishing to the Chrome Web Store actually require?
A one-time developer registration fee and a review from Google before the listing goes live. Review time varies, and Google can reject a submission that requests broader permissions than the extension's behavior justifies - keeping the permission list narrow from the start helps.
Should every repetitive browser task become an extension?
Not always. If the data is reachable through an API, a scheduled automation can often replace the manual click without a browser extension at all. Build the extension version specifically when the task has to happen inside the browser, on a specific page, in response to a click.