How to Use Claude to Vibe Code a Chrome Extension (2026 Guide)
Learn how to use Claude to rebuild expired Chrome extensions from the Chrome Goldmine database. Real Manifest V3 code, monetization patterns, and Web Store approval tips for indie makers.
Article content
A deep-dive tutorial for indie makers, non-technical founders, and developers who want to turn proven, abandoned Chrome extensions into profitable SaaS products — using AI as their co-pilot. If you'd rather see the broader landscape first, start with our vibe coding Chrome extensions pillar or the AI tools comparison.
What "Vibe Coding" a Chrome Extension Actually Means
Before we write a single line of code, let's clarify the term reshaping how indie makers build software in 2026. "Vibe coding" — popularized by Andrej Karpathy — is the practice of describing what you want to an AI, iterating in natural language, and letting the model generate, debug, and refine the code. You provide intent, context, and direction. The AI handles syntax, structure, and boilerplate.
Chrome extensions are architecturally small, self-contained, and bounded — a `manifest.json`, a background service worker, a content script, and an optional popup. That bounded scope makes them ideal for AI-assisted vibe coding. Unlike a sprawling SaaS codebase, a Chrome extension fits inside Claude's context window. You can describe the entire extension in one go, iterate in a single conversation, and ship something real in a weekend.
The strategy in this tutorial: start with The Chrome Goldmine database, identify a proven expired extension that already validated user demand, then use Claude as the primary build engine to recreate and improve it. The database contains 9,656 expired Chrome extensions — 490 classified as "Very High" potential ($100K+/year) and 529 as "High" potential ($50K–$100K/year). These extensions once had real users, real ratings, and real daily utility before disappearing and leaving a gap in the market.
Why Expired Extensions Are the Perfect AI Coding Target
The standard question for any new product is: "Does anyone actually want this?" Expired extensions answer definitively — yes, thousands (sometimes millions) already did. The database includes extensions with up to 38 million users before expiration. You don't need to validate demand. You need to build a better version. For a deeper validation framework, see how to validate an expired extension idea.
This matters for vibe coding because the more context you can give an AI, the better the output. With an expired extension, you already know:
- The exact functionality users relied on (from the original store listing)
- The pain point it solved (visible in user reviews and ratings)
- What competitors exist (the database's Competitor Snapshot column)
- How to differentiate (the Unique Selling Point column)
- The monetization model (Freemium/Paid/Affiliate/Subscription, pre-analyzed)
You feed all of that context to Claude. Instead of starting with "I want to build a Chrome extension that does X," you start with "Here is a proven extension that had 500,000 users before it was abandoned. Here is what it did. Here are its competitors. Here is my differentiation angle. Build me a Manifest V3 version." That is a completely different prompt quality — and it produces completely different output quality.
Step 1: Mining the Database for Your Build Target
The first step has nothing to do with Claude. It's about picking the right target. Open the Chrome Goldmine database and use one of the four pre-configured views:
- View 1 – Top High-Value: Sorted by annual revenue potential. uBlock Origin ($17.1M/year potential, 38M users) is at the top — also the most competitive. Look in the $100K–$500K range where competition is thinner.
- View 2 – By Category & High/Very High Earning Potential: Use this if you already know your niche — Privacy/Security, Developer Tools, Productivity. Niche expertise dramatically improves your Claude prompts.
- View 3 – Interactive Discovery Tool: Filter by Category + Rating + User Count simultaneously. A productivity extension with 50,000 users, 4.2 stars, and "developer abandoned due to job change" is essentially a gift.
- View 4 – Due Diligence: Use this before committing. Check the Competitor Snapshot. "No direct competitors" or "weak alternatives" signals an underserved market.
The ideal target profile for a solo AI-assisted build: 10,000–500,000 users (proven demand, not overwhelming), 3.5–4.5 stars (room to improve), developer-abandonment expiration (not policy violation), Productivity / Developer Tools / Privacy category, no dominant Web Store competitor, Freemium or Subscription monetization. One practical example: a Color Picker / Eyedropper extension with $450K/year potential and 3M users — well-defined functionality, universally understood use case, daily-driver tool for designers, marketers, and developers. For more inspiration, see profitable Chrome extension niches.
Step 2: Setting Up Your Development Environment
Before opening Claude, set up the scaffolding. A clean environment means Claude's code slots in without friction.
- A code editor — VS Code with the Claude.ai side panel open, or Cursor IDE (Claude integrated directly). Lovable.dev users can pair Lovable for the marketing site and admin dashboard while Claude handles the extension code.
- Node.js LTS installed — `node -v` to confirm.
- A folder for your extension: `mkdir my-extension && cd my-extension`.
- Chrome with Developer Mode enabled: `chrome://extensions/` → toggle "Developer mode" → "Load unpacked".
Directory structure Claude will work within:
my-extension/
├── manifest.json ← The brain
├── background.js ← Service worker (Manifest V3)
├── contentScript.js ← Runs on web pages
├── popup.html ← The UI (optional)
├── popup.js ← Popup logic (optional)
├── options.html ← Settings page (optional)
├── options.js ← Settings logic (optional)
└── icons/ ← 16, 48, 128px PNG iconsThe key architectural context for Claude: in Manifest V3 (now required for all new extensions), background pages are replaced by service workers. Service workers are ephemeral — they spin up, handle an event, and shut down. This is the #1 source of bugs when vibe coding extensions with AI, because pre-2023 training data is heavy on Manifest V2 patterns. You must explicitly tell Claude this — see also our breakdown of the most common vibe coding mistakes.
Step 3: Writing Your Master System Prompt
This is the most important section. The quality of your Claude prompts determines the quality of your extension. Generic prompts produce generic code. Specific, contextual prompts produce production-ready code. Start every Chrome extension session with a Master System Prompt pasted at the top of the conversation.
You are an expert Chrome Extension developer specializing in Manifest V3. All code must comply with MV3 — service workers instead of background pages, `chrome.storage.local` instead of `localStorage`, no `eval()` or remote code execution. I am rebuilding an expired Chrome extension from a database of abandoned extensions with proven demand. Target context — Name: [NAME]. Original user count: [USERS]. Rating: [RATING]. Category: [CATEGORY]. What it did: [DESCRIPTION]. Why it expired: [REASON]. Competitors: [SNAPSHOT]. My differentiation: [USP]. Monetization: [FREEMIUM/PAID/SUBSCRIPTION]. Build with vanilla JavaScript, no frameworks unless I ask. Modular, commented, production-ready. Request minimum necessary permissions. For any UI, use a clean minimal design system.
This prompt simultaneously sets architectural constraints (MV3), technical guardrails (no eval, minimal permissions), and business context (proven demand, specific differentiation). Claude's output quality jumps when business context sits alongside technical requirements — it helps the model make trade-off decisions intelligently.
Why Claude Specifically Excels at Extension Code
- Long context window: Claude Sonnet/Opus support 200K tokens. Paste your entire extension codebase and stay coherent.
- Strong instruction following: When you say "Manifest V3 only," Claude stays in that constraint reliably.
- Reasoning about permissions: Claude understands why `tabs` instead of `activeTab` is both a security risk and a Web Store rejection risk.
- Structured code output: Proper indentation, clear comments, logical separation — easy to copy-paste directly into files.
GPT-4o and Gemini Advanced are viable too. Use GPT-4o when you want faster iteration on small edits, Claude when you need deep reasoning about architecture, security, or complex content script interactions. We compare the full lineup in the best AI tools for vibe coding Chrome extensions post.
Step 4: Building the Manifest File First
Never start with the popup or the logic. Always start with `manifest.json` — the contract that tells Chrome what your extension can do. Get it wrong and everything else is invalidated.
Based on the context I gave you, generate a complete `manifest.json` for this extension. Request only strictly necessary permissions. Use Manifest V3 format. Explain each permission and why it's needed.
Real-world example from a Gmail expander rebuild:
{
"manifest_version": 3,
"name": "Trimless for Gmail V3",
"version": "1.2.0",
"description": "Never click 'Show trimmed content' again. Automatically expand clipped Gmail messages.",
"icons": {
"16": "images/icon-16.png",
"48": "images/icon-48.png",
"128": "images/icon-128.png"
},
"background": { "service_worker": "background.js" },
"content_scripts": [{
"matches": ["https://mail.google.com/mail/*"],
"js": ["vendor/jquery-3.7.1.min.js", "contentScript.js"],
"run_at": "document_start"
}],
"permissions": ["storage"],
"host_permissions": ["https://mail.google.com/mail/*"]
}After Claude generates it, follow up with: *"Review this manifest. Are there any permissions I could remove to reduce attack surface? Any that would cause Chrome Web Store rejection in 2026?"* This second pass is critical for store approval — extensions requesting `tabs`, `webNavigation`, or `browsingData` without clear justification get rejected or flagged.
Step 5: Building the Service Worker
The service worker is the extension's orchestrator — it handles events, manages state, and coordinates between parts of your extension. In MV3 it's ephemeral: wakes on events, shuts down when idle.
// Initialize storage on first install
chrome.runtime.onInstalled.addListener(async details => {
if (details.reason !== 'install') return;
await chrome.storage.local.set({
enabled: true,
color: '#888888',
indentation: 32
});
});
// Update toolbar icon based on state
function updateIcon(tabId, isEnabled) {
chrome.action.setIcon({
tabId,
path: {
'19': `images/icon${isEnabled ? '' : '-gray'}-19.png`,
'38': `images/icon${isEnabled ? '' : '-gray'}-38.png`
}
});
}
// Handle toolbar icon clicks
chrome.action.onClicked.addListener(async (tab) => {
const items = await chrome.storage.local.get('enabled');
const newState = !items.enabled;
await chrome.storage.local.set({ enabled: newState });
updateIcon(tab.id, newState);
});- No persistent in-memory state — every time the service worker wakes, variables reset. State lives in `chrome.storage`.
- Async/await everywhere — MV3 Chrome APIs return Promises, not callbacks.
- Event-driven architecture — the service worker only runs in response to events.
Step 6: The Core Build Loop — Content Script Logic
The content script is where the actual functionality lives. It runs inside the web page the user visits and manipulates the DOM.
let isEnabled;
chrome.storage.local.get('enabled').then(items => {
isEnabled = items.enabled;
if (isEnabled) applyFeature();
});
function applyFeature() {
$('.adP').removeClass('adP').addClass('trimless-adP');
$('.im').addClass('trimless-visible');
$('.ajU, .ajV').hide();
}
function removeFeature() {
$('.trimless-adP').removeClass('trimless-adP').addClass('adP');
$('.trimless-visible').removeClass('trimless-visible');
$('.ajU, .ajV').show();
}
chrome.storage.onChanged.addListener((changes, area) => {
if (area === 'local' && changes.enabled) {
isEnabled = changes.enabled.newValue;
isEnabled ? applyFeature() : removeFeature();
}
});Key patterns: reversible changes (apply/remove pairs allow toggling without page reload), storage listeners (react in real-time to settings), and defensive selectors (multiple fallbacks because target sites change DOM).
Step 7: Advanced Prompting — Get Claude to Reason, Not Just Generate
Most vibe coders use AI at 20% of its potential by only asking it to generate code. The real power is using Claude for architectural reasoning, competitive analysis, and UX strategy.
The "Ghost User Review" Prompt
I'm rebuilding [EXTENSION NAME] which had [USERS] users and a [RATING] star rating. Pretend you are 5 different types of users who relied on it daily. Write a user review from each persona — what they loved, what frustrated them, what feature they wish existed. I'll use this to improve my rebuild.
The "Competitive Moat" Prompt
Here is the Competitor Snapshot from my database: [DATA]. Analyze each competitor. For each, identify one weakness in their Chrome Web Store listing (title, description, screenshots, feature gaps). Then tell me what my extension must do better on launch day to win the comparison.
The "Monetization Architecture" Prompt
Combine the prompt below with a payments setup. For Chrome extensions, ExtensionPay is the simplest path; for a full SaaS dashboard around it, plug Claude's output into a starter kit like TurboStarter or Supastarter.
This extension uses a Freemium model. Free tier users get [X features]. Paid tier ($4.99/month) gets [Y features]. Design the feature flag system in JavaScript that controls access. It should: (1) check license status from `chrome.storage.local`, (2) show an upgrade prompt when a free user hits a paid feature, (3) be resistant to simple local manipulation.
let isPaid = false;
let dailyUsage = { date: null, count: 0 };
chrome.storage.local.get(['paid', 'dailyUsage']).then(items => {
isPaid = items.paid || false;
dailyUsage = items.dailyUsage || { date: null, count: 0 };
});
function hasAccess() {
if (isPaid) return true;
const today = new Date().toDateString();
if (dailyUsage.date !== today) dailyUsage = { date: today, count: 0 };
return dailyUsage.count < 5; // Free tier: 5/day
}
async function trackUsage() {
if (isPaid) return true;
if (!hasAccess()) { showUpgradePrompt(); return false; }
dailyUsage.count++;
await chrome.storage.local.set({ dailyUsage });
return true;
}For pricing strategy across the freemium/paid spectrum, our Chrome extension pricing strategy guide breaks down what works.
Step 8: Manifest V3 Pitfalls Claude Helps You Avoid
Pitfall 1: Service Worker Context Loss
In MV3, the service worker terminates after a few seconds of inactivity. Any in-memory state is lost.
// WRONG — state lost when service worker terminates
let userSettings = { theme: 'dark' };
chrome.action.onClicked.addListener(() => {
console.log(userSettings.theme); // may be undefined!
});
// CORRECT — state persists
chrome.action.onClicked.addListener(async () => {
const { userSettings } = await chrome.storage.local.get('userSettings');
console.log(userSettings.theme);
});Pitfall 2: chrome.tabs.executeScript Deprecation
// WRONG — MV2 API (deprecated)
chrome.tabs.executeScript(tabId, {
code: 'document.body.style.backgroundColor = "red";'
});
// CORRECT — MV3 API
chrome.scripting.executeScript({
target: { tabId },
func: () => { document.body.style.backgroundColor = "red"; }
});Pitfall 3: Remote Code Execution
MV3 prohibits executing remotely hosted code — no scripts loaded from a CDN. Ask Claude: *"Scan all our code for any patterns that execute remote code: eval(), new Function(), remotely hosted scripts. Replace with local alternatives."* For a step-by-step replacement guide, see our Manifest V2 replacement walkthrough.
Step 9: Testing Like a Professional
- Service worker lifecycle test: use it 5 min, leave idle 30 min, come back and trigger a feature. If it fails, you have a state issue.
- Cross-origin test: 5 site types — simple HTML, React SPA, WordPress, Gmail, strict-CSP site.
- Permission request test: does Chrome show the dialog clearly? Mismatch = instant rejection.
- Incognito mode test: enable in `chrome://extensions/`, test every feature.
- Update test: increment the version, reload, verify `chrome.storage.local` persists.
Generate a checklist of 15 manual test cases for a Manifest V3 Chrome extension that uses [permissions]. For each test case include: the action, the expected result, and the failure mode it's testing.
Step 10: Chrome Web Store Submission — Using AI to Pass Review
Getting approved by the Web Store review team has gotten significantly harder. Claude can dramatically increase approval rate.
I'm about to submit this Chrome extension. Here is my complete `manifest.json`, my privacy policy, and my store listing. Review everything against Google's Chrome Web Store Developer Program Policies. Identify anything that would cause automatic rejection or flag for manual review.
Every extension collecting any user data needs a privacy policy. Prompt Claude with the exact data fields you store, transmission behavior (none, ideally), analytics usage, and monetization model — it will produce a legally sound draft you can host on a one-pager. Build that landing page in Framer in an afternoon, and capture interest with a MailerLite or Kit signup form before launch day.
For the 5 screenshots and promo tile, ask Claude to write captions that tell a story from "user has a problem" to "extension solves it." Generate the actual visuals in Canva from templates in about 15 minutes.
Step 11: Post-Launch AI Automation
Once your rebuild is live, AI becomes your growth engine. Wire up a Latenode (or n8n) workflow that watches your Chrome Web Store listing for new reviews and pipes them to Claude:
Here is a new 1-star review: [REVIEW]. Classify it as (1) genuine bug, (2) user error, (3) feature request, or (4) competitor attack. If it's a bug, suggest the code change. Then write a professional, helpful public reply I can post.
After each update, feed Claude the git diff and ask for three formats: a technical changelog for GitHub, a user-friendly description for the Web Store listing, and a tweet announcing the update. For the deep dive on wiring Lovable + Latenode end-to-end, see our Lovable + Latenode integration guide.
Step 12: Scaling From One Extension to a Portfolio
The Chrome Goldmine database contains 9,656 expired extensions. The biggest asymmetric opportunity isn't building one great extension — it's building a portfolio of 5–10 small, focused extensions across categories, each with a freemium model, each generating $500–$5,000/month.
With vibe coding, the marginal cost of building extension #5 is dramatically lower than extension #1. Your Claude system prompts improve, your MV3 patterns solidify, store listing templates exist, and your privacy policy just needs light editing.
- One anchor extension ($50K–$100K potential from the "High" category)
- Three utility extensions ($10K–$50K potential from the "Moderate" category)
- Two experimental extensions from underserved categories
Build the anchor first. Use the revenue and learnings to fund and accelerate the utilities. By extension #3, your workflow will be refined enough to ship a working MVP in 4–6 hours. Cross-promotion from inside the Chrome Web Store is free — every listing can mention your other extensions, building a brand moat solo builders rarely achieve. For solo-builder economics specifically, read vibe coding for solo Chrome extension makers.
The AI Stack That Wins for Chrome Extension Vibe Coding
| Phase | Best AI Tool | Why |
|---|---|---|
| Research & target selection | Claude or GPT-4o | Long reasoning for strategy |
| System prompt crafting | Claude | Instruction following |
| manifest.json generation | Claude | Permission reasoning |
| Core JS logic | Claude Sonnet | Code quality & MV3 accuracy |
| UI/popup HTML+CSS | GPT-4o or Claude | Fast visual iteration |
| Debugging errors | Claude | Explains root cause clearly |
| Store listing copy | Claude | Long-form persuasive writing |
| Privacy policy | Claude | Structured legal text |
| Icon generation | DALL-E 3 / Midjourney | Visual assets |
| Review responses | GPT-4o | Shorter, faster replies |
Claude isn't always the right tool for every task — but it is the right tool for the architectural and reasoning-heavy tasks that determine whether your extension is approved and whether it retains users.
From Database Row to Live Extension: The Realistic Timeline
- Day 1 (3–4h): Browse Chrome Goldmine, select target, research competitors, finalize differentiation, write Master System Prompt.
- Day 2 (4–6h): Vibe code with Claude — manifest, service worker, content script, popup. First test cycle, first debug loop.
- Day 3 (3–4h): UI polish, monetization gate, hardening prompt, MV3 checklist.
- Day 4 (2–3h): Store listing copy with Claude, privacy policy, screenshots, minimal landing page.
- Day 5 (1–2h): Submit to Chrome Web Store. Review takes 1–3 business days for new accounts.
Total wall-clock time: 13–19 hours from database row to live extension. Compare that to weeks of learning Chrome APIs, writing boilerplate from scratch, and debugging MV3 migration issues blindly. AI-assisted doesn't just save time — it raises the quality ceiling for what a solo maker can ship.
Why the Chrome Goldmine Database Is Your Unfair Advantage
Every element of a strong Claude prompt relies on context. The more specific the context, the better the code and the strategy. This is where The Chrome Goldmine acts as your unfair advantage over every other indie maker vibe coding from scratch. You're feeding Claude proven demand signals, pre-analyzed monetization models, revenue projections, competitor intel, differentiation angles, and the reason the last builder failed.
That last point is underrated. Knowing an extension expired because "developer changed jobs" vs. "policy violation" vs. "app moved to standalone web" completely changes your strategy. A policy violation extension might be dead for good reason. A developer abandonment is an open door with the welcome mat still out. The 490 "Very High" potential extensions in the database — each with $100K+/year projected revenue — represent 490 open doors. With Claude as your build partner and the database as your roadmap, the only bottleneck is your willingness to start.
Final Thoughts: Vibe Coding Is Leverage, Not Cheating
There's a developer gatekeeping attitude that dismisses vibe coding as "not real programming." Ignore it. Every generation has used leverage — higher-level languages, frameworks, libraries, package managers — to ship faster. AI is the next layer, and it's a big one.
What matters is whether users' problems get solved, whether the code runs reliably, whether the extension passes review, and whether the revenue comes in. Claude doesn't care about your impostor syndrome. It just wants a good prompt. The Chrome Goldmine gives you 9,656 reasons to start.
Ready to pick your first target? Browse the Chrome Goldmine database, then circle back to our 30-minute Claude tutorial for a beginner-friendly warm-up before diving into your first rebuild.
