DEV Community: Sujal Meena

Building a Local-First Chrome Extension with IndexedDB and Ollama

Sujal Meena — Tue, 02 Jun 2026 07:41:23 +0000

Most modern browser AI reading assistants operate in the cloud. Every time you ask a question or read a page, your browsing history, active tabs, and queries are shipped off to a proprietary backend database.

I wanted a private, zero-subscription reading companion that ran 100% locally on my machine.

To solve this, I built ContextBridge—a Chrome extension that sits in your sidebar, indexes web pages to Markdown, stores them locally, and lets you chat with them offline using local LLMs via Ollama.

In this article, I’ll walk through the architectural choices of building a local-first extension using Chrome’s Manifest V3, IndexedDB, and Ollama.

The Architecture: Why Local-First in a Browser?
Building a local-first system within a browser sandbox presents unique challenges and benefits:

[ Active Webpage ] ──(Ctrl+Shift+E)──> [ DOM-to-Markdown Extractor ]
│
▼
[ Ollama (localhost) ] <───(Direct API)─── [ Extension Sidebar ] <───> [ IndexedDB (Local Store) ]

No Backend Middleman: The sidebar connects directly to your local Ollama port. Your API keys for cloud fallbacks (like Claude or Gemini) are stored strictly in chrome.storage.local.

IndexedDB over LocalStorage: For storing larger document indexes, chunked text, and metadata, localStorage is too restrictive (5MB limit and synchronous). IndexedDB provides asynchronous, high-capacity structured storage.

No Bundlers, No Bloat: The extension is built in vanilla JS with zero external dependencies, making load times instant.

💾 Storing the Web: Implementing IndexedDB
We need a clean utility to manage IndexedDB without adding large NPM wrappers. Here is a simple, robust vanilla Javascript DB wrapper that manages our pages:

javascript
class ContextStore {
constructor() {
this.dbName = 'ContextBridgeDB';
this.dbVersion = 1;
this.db = null;
}
async init() {
return new Promise((resolve, reject) => {
const request = indexedDB.open(this.dbName, this.dbVersion);
request.onerror = () => reject(request.error);
request.onsuccess = () => {
this.db = request.result;
resolve(this);
};
request.onupgradeneeded = (event) => {
const db = event.target.result;
if (!db.objectStoreNames.contains('pages')) {
const store = db.createObjectStore('pages', { keyPath: 'url' });
store.createIndex('domain', 'meta.domain', { unique: false });
store.createIndex('indexedAt', 'indexedAt', { unique: false });
}
};
});
}
async savePage(pageData) {
return new Promise((resolve, reject) => {
const transaction = this.db.transaction(['pages'], 'readwrite');
const store = transaction.objectStore('pages');
const request = store.put({
...pageData,
indexedAt: Date.now()
});
request.onsuccess = () => resolve();
request.onerror = () => reject(request.error);
});
}
}
🤖 Direct Sidebar Integration with Ollama
Ollama exposes a beautiful HTTP API locally (by default at http://localhost:11434). The primary challenge when communicating from a Chrome extension sidebar to localhost is CORS (Cross-Origin Resource Sharing).

Fortunately, in Manifest V3, background scripts and sidebar panels have special network privileges. As long as the extension requests the appropriate host permissions in the manifest.json, it can bypass standard browser CORS restrictions and hit localhost directly:

json
{
"permissions": [
"activeTab",
"storage",
"sidePanel"
],
"host_permissions": [
"http://localhost:11434/*"
]
}
Here is the exact fetch logic we use in the sidebar to stream responses from local models (like llama3 or mistral) with the bounding context of the active page:

javascript
async function* askLocalOllama(modelName, systemPrompt, userMessage) {
const response = await fetch('http://localhost:11434/api/chat', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
model: modelName,
messages: [
{ role: 'system', content: systemPrompt },
{ role: 'user', content: userMessage }
],
stream: true
})
});
if (!response.ok) throw new Error('Ollama connection failed.');
const reader = response.body.getReader();
const decoder = new TextDecoder();
let buffer = '';
while (true) {
const { done, value } = await reader.read();
if (done) break;
buffer += decoder.decode(value, { stream: true });
const lines = buffer.split('\n');
buffer = lines.pop(); // Keep partial line in buffer
for (const line of lines) {
if (!line.trim()) continue;
const json = JSON.parse(line);
if (json.message && json.message.content) {
yield json.message.content;
}
}
}
}
Lessons Learned

Keep it Vector-less when possible: For single-page chats, loading full vector embeddings in-browser is overkill. Passing semantically chunked text directly in the LLM context window is much faster and completely reliable.

Offline-First is a UX Superpower: Loading the extension instantly without loading spinners or spinner overlays makes the extension feel incredibly premium.

Check out the full open-source codebase here: github.com/sujalmeena7/ContextBridge

If you enjoyed this, feel free to drop a star on the repo or ask any questions in the comments below!

ContextBridge – Local RAG Companion - Chrome Web Store

Store, search, and chat with web page content locally. AI chat (BYOK), full-text search, markdown export, and optional RAG endpoint.

chromewebstore.google.com

I built an AI that writes launch posts in your voice — here's the full technical breakdown

Sujal Meena — Sun, 17 May 2026 17:30:30 +0000

I'm a 3rd year CS student. Every time I shipped a side
project I spent 2 hours writing the same announcement
6 different ways.

Reddit wants casual. HN wants technical. Product Hunt
wants punchy under 60 characters. IndieHackers wants
honest numbers and vulnerability.

Every AI tool I tried produced the same generic output
that got flagged by Reddit's spam filters immediately.

So I built OmniLaunch. Here's exactly how it works.

The core problem with AI writing tools

Every AI writing tool has the same flaw.

Feed the same prompt to ChatGPT and you get identical
output regardless of who you are. "In today's
fast-paced world, leveraging synergies to unlock
value..." — you know the vibe.

The fix isn't a better prompt. It's training on YOUR
writing specifically using embeddings.

Architecture overview

The system has 5 main components:

Voice Lab — ingests writing samples, generates embeddings
LangGraph agent pipeline — 3 agents per platform
SSE streaming — real-time generation progress
Validation engine — platform rule enforcement
Razorpay billing — subscription management

Let me break down each one.

Voice cloning with text-embedding-004

When a user pastes their writing samples, I convert
them into a 768-dimensional vector using Google's
text-embedding-004 model:

async def generate_style_embedding(
    text: str
) -> list[float]:
    result = genai.embed_content(
        model="models/text-embedding-004",
        content=text,
        task_type="SEMANTIC_SIMILARITY"
    )
    return result['embedding']

That vector gets stored in Supabase using pgvector:

ALTER TABLE voice_profiles 
ADD COLUMN style_embedding VECTOR(768);

Every generated draft gets embedded using the same
model. Voice match score is cosine similarity between
the draft embedding and the stored profile:

def compute_cosine_similarity(
    vec_a: list[float],
    vec_b: list[float]
) -> float:
    a = np.array(vec_a)
    b = np.array(vec_b)
    dot = np.dot(a, b)
    norm = np.linalg.norm(a) * np.linalg.norm(b)
    if norm == 0:
        return 0.0
    return float(dot / norm)

def normalize_cosine_to_score(
    cosine_sim: float
) -> float:
    # Map [-1, 1] to [0, 1]
    return (cosine_sim + 1.0) / 2.0

The LangGraph pipeline

Three agents run sequentially per platform:

1. Context Research Agent

Fetches live platform rules from the database on
every generation — not hardcoded. Reddit flair
requirements change. HN's 80 character limit is
strict. PH taglines must be under 60 characters.

async def context_research_node(
    state: PipelineState
) -> dict:
    platform = state["platform"]
    rules = await fetch_platform_rules(platform)
    await progress_callback(
        platform, "researching", 
        f"Fetched rules for {platform}"
    )
    return {"platform_constraints": rules}

2. Drafting Agent

Takes the Tone Manifesto + platform constraints +
product description. Generates a first draft via
Gemini with a platform-specific system prompt:

system_prompt = f"""
You are writing a {platform} post for a developer.

VOICE PROFILE:
{json.dumps(tone_manifesto, indent=2)}

PLATFORM RULES:
- Title max: {constraints['title_max_chars']} chars
- Forbidden words: {constraints['forbidden_words']}
- Required prefix: {constraints.get('prefix', 'none')}
- Tone: {constraints['tone']}

Write in the user's voice exactly. Match their 
sentence length, formality, emoji usage.
NEVER use: {', '.join(AI_ISMS[:5])}...
"""

3. Humanizer Agent

The most important agent. Three responsibilities:

First — removes AI-isms. 50+ patterns:

AI_ISMS = [
    "in today's fast-paced world",
    "game-changer",
    "revolutionary",
    "unlock your potential", 
    "dive into",
    "leverage",
    "seamlessly",
    "it's worth noting",
    "certainly",
    # 40+ more...
]

Second — scores voice match via cosine similarity.

Third — if score < 0.85, sends back to drafter
with specific feedback. Max 3 revision loops.

The routing logic

def route_after_humanize(
    state: PipelineState
) -> str:
    if (state["voice_match_score"] < 0.85 
            and state["revision_count"] < 3):
        return "drafting"
    return "end"

graph.add_conditional_edges(
    "humanizing",
    route_after_humanize,
    {"drafting": "drafting", "end": END}
)

LangGraph merges the returned dict into state before
evaluating the conditional edge — so route_after_humanize
always sees the freshly updated score and revision count.

Real-time progress with SSE

Bundle generation runs as a Celery task. The frontend
watches progress via Server-Sent Events:

// hooks/useBundleSSE.ts
const useEffect(() => {
  if (!bundleId || !token) return;

  const es = new EventSource(
    `/api/v1/bundles/${bundleId}/status?token=${token}`
  );

  es.onmessage = (event) => {
    const data = JSON.parse(event.data);

    if (data.status === 'complete') {
      es.close();
      fetchFinalBundle();
      return;
    }

    if (data.status === 'failed') {
      es.close();
      showError(data.detail);
      return;
    }

    updateProgress(data);
  };

  es.onerror = () => {
    es.close();
    fallbackToPolling();
  };

  return () => es.close();
}, [bundleId, token]);

One gotcha: EventSource doesn't support custom headers
so the JWT goes as a query parameter. Make sure your
backend validates it identically to header auth:

@router.get("/bundles/{bundle_id}/status")
async def stream_bundle_status(
    bundle_id: str,
    token: str = Query(...),  # JWT from query param
    db: AsyncSession = Depends(get_db)
):
    user = await verify_token(token)  # same as header auth
    # ... SSE logic

The MV3 chrome.alarms gotcha

While building Tab Hibernator Pro (a Chrome extension
I shipped before this), I hit the most frustrating
MV3 bug.

Most developers use setInterval for background timers:

// BROKEN in MV3 — service worker sleeps
setInterval(checkTabs, 60000)

Service workers in MV3 go idle after ~30 seconds.
Your setInterval dies silently. Everything works in
DevTools (which keeps the worker alive) and breaks
in production.

The fix:

// CORRECT — alarms survive service worker sleep
chrome.alarms.create('hibernation-check', {
  delayInMinutes: 1,
  periodInMinutes: 1
});

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'hibernation-check') {
    checkAndHibernateTabs();
  }
});

chrome.alarms persists independently of the service
worker lifecycle. This is documented but easy to
miss and impossible to debug until you know it.

Mistakes I made

Started with URL scraping for voice samples

My original spec scraped the user's Reddit and HN
posts using Playwright. 300MB Chromium install, rate
limiting, bot detection, flaky tests. Replaced it
with a simple textarea — paste 3-5 writing samples.
Simpler and works better.

setInterval in the service worker (see above)

Burned 2 days debugging why the extension worked
perfectly in testing and broke immediately in
production.

No rate limiting on LLM endpoints

Added slowapi after the architecture was complete.
Should have been there from day one. One user
hammering generate can burn your entire Gemini
quota in minutes:

from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)

@router.post("/generate-launch-bundle")
@limiter.limit("5/minute")
async def generate_bundle(request: Request, ...):
    ...

Building LangGraph before the pipeline worked

Spent time learning LangGraph's API while the
basic pipeline wasn't even tested end-to-end.
Should have built a working custom loop first,
then migrated to LangGraph once the logic was
proven.

What I'd do differently

Build the boring version first. Polling before SSE.
Custom loop before LangGraph. Text paste before URL
scraping. The boring version is easier to debug and
gives you something to show people faster.

Rate limit everything that touches an LLM on day one.

Don't scrape when an API or simple text input works.

How I built an AI that writes launch posts in your voice — not generic ChatGPT slop

Sujal Meena — Sat, 16 May 2026 08:20:46 +0000

Every time I shipped a side project, I spent 2 hours
writing the same announcement 6 different ways.

Reddit wants casual. Hacker News wants technical.
Product Hunt wants punchy under 60 characters.
IndieHackers wants transparency and honest numbers.

I tried using ChatGPT. The output was generic, got
flagged by Reddit's spam filters immediately, and
sounded nothing like me. So I built OmniLaunch.

Here's exactly how it works technically.

The core problem with AI writing tools

Every AI writing tool has the same flaw — it produces
identical output for everyone. Feed the same prompt to
ChatGPT and you get the same "In today's fast-paced
world" energy regardless of who you are.

The fix isn't a better prompt. It's training the model
on YOUR writing specifically.

How voice cloning actually works

When a user pastes their writing samples, here's what
happens under the hood:

async def generate_style_embedding(text: str) -> list[float]:
    result = genai.embed_content(
        model="models/text-embedding-004",
        content=text,
        task_type="SEMANTIC_SIMILARITY"
    )
    return result['embedding']  # 768-dimensional vector

We use Google's text-embedding-004 model to convert
the user's writing into a 768-dimensional vector. This
vector captures the semantic fingerprint of how they
write — not just the words, but the patterns.

That vector gets stored in Supabase using pgvector:

style_embedding VECTOR(768)

The LangGraph agent pipeline

The generation pipeline has 4 agents running in sequence:

1. Context Research Agent
Fetches live platform rules from the database —
Reddit flair requirements, HN's 80 character title
limit, Product Hunt's 60 character tagline limit.
Rules change so we fetch fresh on every generation.

2. Drafting Agent
Takes the user's Tone Manifesto (a JSON description
of their writing style) + platform constraints +
product description and generates a first draft via
Gemini.

The system prompt enforces platform rules hard:

system_prompt = f"""
You are writing a {platform} post for a developer.

VOICE PROFILE:
{json.dumps(tone_manifesto, indent=2)}

PLATFORM RULES:
- Title max: {constraints['title_max_chars']} characters
- Forbidden words: {constraints['forbidden_words']}
- Required prefix: {constraints.get('prefix', 'none')}

Write in the user's voice. Match their sentence 
length, formality level, and emoji usage exactly.
"""

3. Humanizer Agent
This is the most important agent. It does 3 things:

First — removes AI-isms. We maintain a list of 50+
phrases that signal AI-generated content:

AI_ISMS = [
    "in today's fast-paced world",
    "game-changer",
    "revolutionary", 
    "unlock your potential",
    "dive into",
    "leverage",
    "seamlessly",
    "it's worth noting",
    "certainly",
    # ... 40+ more
]

Second — scores voice match using cosine similarity:

def compute_cosine_similarity(
    vec_a: list[float], 
    vec_b: list[float]
) -> float:
    a = np.array(vec_a)
    b = np.array(vec_b)
    dot = np.dot(a, b)
    norm = np.linalg.norm(a) * np.linalg.norm(b)
    if norm == 0:
        return 0.0
    return float(dot / norm)

def normalize_cosine_to_score(cosine_sim: float) -> float:
    return (cosine_sim + 1.0) / 2.0

Third — if the voice match score is below 0.85, it
sends the draft back to the Drafting Agent with
specific feedback. Maximum 3 revision loops.

4. LangGraph routing

The revision loop is handled by a conditional edge:

def route_after_humanize(state: PipelineState) -> str:
    if (state["voice_match_score"] < 0.85 
            and state["revision_count"] < 3):
        return "drafting"
    return "end"

graph.add_conditional_edges(
    "humanizing",
    route_after_humanize,
    {"drafting": "drafting", "end": END}
)

The MV3 gotcha that killed most tab suspenders

While building Tab Hibernator Pro (a Chrome extension
I shipped before this), I learned the hard lesson about
Manifest V3 service workers.

Most developers use setInterval for background timers:

// WRONG in MV3 — service worker goes to sleep
setInterval(checkTabs, 60000)

Service workers in MV3 go idle after ~30 seconds of
inactivity. Your setInterval dies silently. The fix:

// CORRECT — alarms persist through service worker sleep
chrome.alarms.create('hibernation-check', {
  delayInMinutes: 1,
  periodInMinutes: 1
});

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'hibernation-check') {
    checkAndHibernateTabs();
  }
});

The alarm API persists independently of the service
worker lifecycle. This is documented but easy to miss
and impossible to debug because DevTools keeps the
service worker alive — so everything works in testing
and breaks in production.

Real-time generation with SSE

Bundle generation runs as a Celery task. The frontend
watches progress via Server-Sent Events:

// useBundleSSE.ts
const eventSource = new EventSource(
  `/api/v1/bundles/${bundleId}/status?token=${token}`
);

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);

  if (data.status === 'complete') {
    eventSource.close();
    fetchFinalBundle();
  }

  if (data.status === 'failed') {
    eventSource.close();
    showError(data.detail);
  }

  updateProgress(data);
};

// Cleanup on unmount
return () => eventSource.close();

Note: EventSource doesn't support custom headers so
the JWT goes as a query parameter. Make sure your
backend validates it the same way as header auth.

What I'd do differently

Start with text-paste, not URL scraping

My original spec included scraping the user's Reddit
and HN posts for voice samples. Playwright on a server
is a nightmare — 300MB Chromium install, rate limiting,
bot detection. I replaced it with a simple textarea
asking users to paste 3-5 samples of their writing.
Simpler, faster, works better.

Rate limit LLM endpoints from day one

I added slowapi after the fact. Should have been
there from the start:

from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)

@router.post("/generate-launch-bundle")
@limiter.limit("5/minute")
async def generate_bundle(request: Request, ...):
    ...

One user hammering the endpoint burns your entire
Gemini quota in minutes.

Polling before SSE

I built polling first and SSE second. This was the
right order — polling is simpler to debug, SSE is
better UX. Build the boring version first.

The stack

Backend: FastAPI + LangGraph + Celery + Redis
Database: Supabase + pgvector
AI: Google Gemini + text-embedding-004
Frontend: Next.js 14 + Tailwind v4 + Framer Motion
Billing: Razorpay
Deployment: Vercel (frontend) + Render (backend)

Try it

OmniLaunch is live with a 14-day free trial and
3 free launches forever.

omni-launch-coral.vercel.app

Built this solo in ~3 weeks. Happy to answer any
questions about the LangGraph pipeline, the embedding
approach, or the MV3 chrome.alarms gotcha.

I built a "Tab Hibernator" to save my RAM (and my sanity)

Sujal Meena — Thu, 14 May 2026 18:57:51 +0000

We’ve all been there. You start your day with one tab for documentation. Three hours later, you have 47 tabs open, your laptop fan sounds like a jet engine, and Chrome is eating 8GB of RAM for breakfast.

I tried existing solutions, but they were either outdated (Manifest V2), clunky, or—worse—they'd hibernate a tab while I was halfway through filling out a long form.

So, I decided to build Tab Hibernator Pro.

💡 The Problem
Modern browsers are memory hogs. Even if you aren't looking at a tab, it’s still consuming resources. While "Memory Saver" exists in Chrome, I wanted something more granular, more transparent, and frankly, more "pro."

🛠️ How I built it (The Tech Stack)
I wanted this to be lightweight and modern, so I stuck to:

Manifest V3: Using Service Workers instead of persistent background pages.
Vanilla JS & CSS: No heavy frameworks. Just pure, optimized performance.
Glassmorphism UI: I spent way too much time making the popup look like a premium SaaS dashboard.
The "Smart" part of Smart Hibernation
The biggest challenge was ensuring the extension doesn't kill something important. I implemented a few key checks:

Media Detection: If YouTube or Spotify is playing, the tab stays alive.
Form Protection: It scans for active inputs. If you've started typing, it won't hibernate.
State Persistence: When you click a hibernated tab, it doesn't just reload; it restores your scroll position.
✨ Key Features
🚀 RAM Recovery Engine: Saves ~80MB of RAM per hibernated tab.
🌑 Premium Dark Mode: A sleek UI with real-time stats.
⚙️ Custom Timeouts: Hibernate after 5 minutes or 4 hours—your choice.
🛡️ Privacy First: Everything stays on your machine. No tracking, no cloud.
🧠 Lessons Learned
Transitioning to Manifest V3 was a learning curve. Moving from a persistent background script to an event-based service_worker meant I had to rely heavily on the chrome.alarms API for the inactivity sweep. It forced me to write cleaner, more asynchronous code.

🔗 Check it out
The project is completely open-source. If you’re a "tab hoarder" like me, I’d love for you to try it out or even contribute!

Tab Hibernator Pro - Chrome Web Store

Automatically suspends inactive tabs to free RAM. Smarter, faster, and privacy-first.

chromewebstore.google.com

What’s your tab management strategy?
Do you close them religiously, or do you let them pile up until your browser crashes? Let’s chat in the comments! 👇

I Built a Chrome Extension That Writes LinkedIn DMs Using Claude AI

Sujal Meena — Mon, 11 May 2026 19:56:15 +0000

The Problem

Every time I wanted to connect with someone on LinkedIn,
I'd spend way too long staring at a blank message box.

Generic messages like "I'd love to add you to my network"
get ignored 90% of the time.

Personalized messages work — but writing them manually
for every single person is exhausting.

So I automated it.

What I Built

ConnectAI — a Chrome Extension that scrapes any
LinkedIn profile and generates 3 personalized connection
request messages using the Anthropic Claude API.

Live on Chrome Web Store: [YOUR LINK]

How It Works

1. Content Script — LinkedIn Scraper

The content script runs on any linkedin.com/in/* page
and scrapes:

Full name
Current role / headline
Current company
Top 3 skills
Recent activity snippet
Profile URL

function scrapeProfile() {
  const profileData = {};

  profileData.fullName = getMultipleTexts([
    "h1.text-heading-xlarge",
    "h1[class*='heading']",
    "h1"
  ]);

  profileData.currentRole = getMultipleTexts([
    ".text-body-medium.break-words",
    ".pv-top-card .text-body-medium"
  ]);

  // Store in chrome.storage.local
  chrome.storage.local.set({ profileData });
}

The trickiest part? LinkedIn is a React SPA that
constantly changes its class names. I had to use
multiple selector fallbacks for every field.

2. Background Service Worker — Claude API Call

I route all API calls through the background service
worker instead of calling directly from the popup.

Why? CORS. The popup can't make direct API calls
to external URLs in MV3.

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === "GENERATE_MESSAGES") {
    handleGenerateMessages(message.payload)
      .then(result => sendResponse({ success: true, data: result }))
      .catch(err => sendResponse({ success: false, error: err.message }));
    return true; // Keep channel open for async
  }
});

3. Claude Prompt Engineering

Getting Claude to return consistent JSON under
300 characters per message took some iteration.

The system prompt enforces strict rules:

Never use "I came across your profile"
Always reference something specific
Sound like a peer, not a fan
Strict JSON output format

const systemPrompt = `
You are a LinkedIn outreach specialist.

STRICT RULES:
1. Each message MUST be under 300 characters
2. NEVER use "I came across your profile"
3. Reference something SPECIFIC about the target
4. Sound human — not AI-generated

OUTPUT: strict JSON only, no markdown
`;

4. Popup UI

The popup is 420px wide with a dark theme and shows:

Scraped target profile info
Your saved sender info (editable inline)
4 purpose pills (networking, referral, etc.)
Generate button
3 message cards with character count badges
One-click copy

Character count badge logic:

🟢 Green = under 300 chars (LinkedIn limit)
🔴 Red = over 300 chars

Tech Stack

Part	Tech
Extension	Manifest V3
Language	Vanilla JS (no bundler)
AI	Anthropic Claude API
Storage	Chrome Storage API
Scraping	Content Scripts
Styling	Pure CSS, dark theme

Biggest Challenges

1. LinkedIn DOM Scraping
LinkedIn changes class names constantly and uses
React under the hood. Had to write multiple selector
fallbacks and re-scrape on SPA navigation using
a MutationObserver.

2. CORS in MV3
Popup can't make external API calls directly.
Solved by routing everything through the background
service worker using chrome.runtime.sendMessage.

3. Consistent JSON from Claude
Claude sometimes wraps JSON in markdown code fences.
Added a cleaning step to strip backticks before
JSON.parse() with a fallback regex extraction.

What's Next

[ ] Auto-detect purpose from profile context
[ ] Message history per profile
[ ] Custom tone settings
[ ] Firefox support

Try It

Chrome Web Store: https://chromewebstore.google.com/detail/cjfnhjpheldgcfmipcmibbmlfmpflfij?utm_source=item-share-cb
GitHub: https://github.com/sujalmeena7/Connect-AI

You need a free Anthropic API key to use it.
New accounts get $5 free credits — enough for
~500 message generations.

If you've built Chrome Extensions before, I'd love
to know how you handle LinkedIn's DOM changes.
Drop your approach in the comments 👇