Coder Legion - Recent posts tagged extension

🚀 Managing MCP Servers in VS Code? Explore SEOSiri MCP Suite Manager!

Thu, 15 Oct 2026 15:41:32 +0000

As AI-powered development evolves, managing Model Context Protocol (MCP) integrations is becoming an important part of building connected developer workflows. A well-organized MCP setup can help developers connect AI tools with external services, tools, and data sources.

🛠️ Meet SEOSiri MCP Suite Manager

Explore our VS Code extension for MCP server management and developer workflows.

💡 Why explore MCP management?
🔹 Developer Productivity: Organize your MCP-related development workflow within VS Code.
🔹 AI Tool Integration: Explore MCP server configurations for compatible AI clients and development environments.
🔹 Workflow Optimization: Simplify the process of working with MCP server setups.
🔹 Developer Ecosystem: Build toward more connected AI-assisted development workflows.
🔹 Project Opportunities: Get in touch with SEOSiri for development, optimization, and digital marketing support.

🔗 Visit the SEOSiri Visual Studio Marketplace:
https://marketplace.visualstudio.com/publishers/seosiri

📦 Get MCP Suite Manager:
https://marketplace.visualstudio.com/items?itemName=SEOSiri.seosiri-vscode-mcp-manager

🤝 Need help developing, optimizing, or marketing your developer product? DM SEOSiri to discuss your project and potential collaboration.

The future of AI development depends not only on capable models, but also on the tools and integrations that connect them.

Build. Integrate. Optimize. Make it discoverable.

MCP #ModelContextProtocol #VSCode #AIDevelopment #DeveloperTools #SEOSiri

Vue.js Web Browser Extension Template

Sun, 04 Oct 2026 18:51:54 +0000

Starting out with browser extensions can often be a pain in the back.

A while back, I was looking for a template I could use to build Epubespiar. Most of the ones I tried had the same problem: I couldn’t get them started and running. Since this was my first time building an extension, that was really frustrating.

The instructions would say something like: clone the project, pnpm install, then pnpm run dev. After that, Chrome would suddenly open and... voilà. A blank tab, staring at you as if asking, "what are you doing, bruv?" And if you didn't have Chrome installed and wanted to check the template UI in Firefox, hell broke loose. :P

So you'd end up back in a 500+ line codebase, trying to figure out what was actually breaking and that can be demoralizing, yeah. Imagine signing up to a social platform and, on first impression... not being able to create posts or publish content the way you would on other apps. Sucks, right?

After a few trials, I decided to build Epubespiar from the ground up with Vue.js. Since then, life has been good.

Recently, that experience stuck with me, so I built a browser extension template to help developers get their extensions up much quicker.

All you need is the repo in your dev environment, then:

pnpm install thereafter, pnpm run dev:all

What you see next should feel familiar, and if you're a web developer, it's even easier, because it follows the same flow you already use day to day. The UI runs on localhost which you can open in any browser, be it Chromium-based or Gecko/Firefox for testing.

Try it here: https://github.com/rezzcode/vuejs-extensions.git and tell me what you think.

api-performance-profiler

Mon, 28 Sep 2026 04:48:58 +0000

As backend developers, we often fly blind when building APIs locally. You write a route, but you don't really know how fast it runs until you leave your editor, set up Postman,
or configure a heavy APM tool.

I wanted performance testing to feel native and frictionless, so I built an open-source, zero-dependency local profiling extension for Node.js (Express & NestJS). 

Here is what it brings directly to your editor:

🟢 Inline Latency Metrics: See real-time execution speeds (e.g., 🟢 84ms) rendered right beside your route definitions in the code.
🚀 1-Click Load Testing: A '▶ Load test' CodeLens sits directly above your route. Click it to replay the last recorded request 1,000 times under heavy load, simulating real

traffic instantly.

📊 Routes Dashboard: A dedicated VS Code sidebar showing all observed routes in your app, sorted from slowest to fastest.
🔐 100% Local & Secure: Everything is stored in local memory. No cloud accounts, no external dashboards, and no bloated tracking dependencies. 

It takes less than a minute to set up—just install the lightweight middleware and the VS Code extension, and your editor comes alive with performance data.

I’d love for you to try it out on your local Express or NestJS projects! Let me know your thoughts, feature requests, or feedback in the comments.

Trying to intercept Slack push notifications from a Chrome extension. Here's why it's Impossible

Tue, 08 Sep 2026 07:57:05 +0000

After I published my last article about building a Chrome extension that speaks browser notifications aloud, a commenter asked a question I didn't have a good answer to.

He pointed out that a lot of web apps — Slack, Gmail, most modern tools — fire their notifications from a service worker via registration.showNotification(), not from the page's JavaScript context. My MAIN world override of window.Notification would never reach those.

He was right. And I told him I'd look into it.

I spent a week researching whether there was any way to close that gap. There isn't. But the reason why is more interesting than a simple "no."

Two ways a website can show you a notification

When a website sends you a browser notification, it can do it in one of two ways.

The first is the constructor path. The page's own JavaScript calls new Notification("You have a message") directly. This is common for in-tab alerts, real-time updates when you're actively on the site, or any notification triggered by something you just did.

The second is the push path. The browser receives a push event from the website's server, wakes up the website's service worker in the background, and the service worker calls self.registration.showNotification() from inside its own scope. This is what happens when Slack notifies you of a new message while the tab is closed or backgrounded. The page never runs. No page JavaScript ever fires.

My extension catches the first path. The MAIN world content script overrides window.Notification before any page code runs. But the service worker never touches the page's window. It has no window. It runs in a completely isolated thread, completely separate from the page, and calls showNotification on itself.

The override is never reached.

Why can't the extension reach the service worker?

This is the part that took me a week to fully accept.

Chrome extensions can inject content scripts into web pages. They can run code in the MAIN world or the ISOLATED world of a page. They can observe network requests, intercept navigations, and modify headers.

What they cannot do is inject code into a third-party website's service worker.

Service workers operate in a separate thread with no DOM, no window, and no connection to the page's JavaScript context. The Chrome Extensions API simply does not offer a mechanism to run extension code inside an arbitrary third-party service worker scope. It's a hard security boundary — and for good reasons. Allowing extensions to arbitrarily patch service workers for any website on the internet would be a significant attack surface.

So: the extension lives on the page side. The push notification lives on the service worker side. There is a wall between them.

Three approaches I investigated

I didn't accept "impossible" without looking for workarounds. Here's what I found.

Approach 1: Override ServiceWorkerRegistration.prototype.showNotification in the MAIN world

A page's JavaScript can call navigator.serviceWorker.ready.then(reg => reg.showNotification(...)). If you override ServiceWorkerRegistration.prototype.showNotification in the MAIN world, you'd intercept that pattern.

The problem: Slack's push notifications don't come from page JavaScript. They come from inside the service worker script itself, where it calls self.registration.showNotification(). The service worker runs in its own scope. The MAIN world prototype override doesn't reach there.

This approach catches one narrow pattern and misses the actual push notification path entirely.

Approach 2: chrome.debugger API with CDP

This is the most discussed workaround in the Chromium Extensions community. The chrome.debugger API gives an extension access to the Chrome DevTools Protocol. With CDP's Fetch.fulfillRequest command, you can intercept a network response — including a service worker JavaScript file — and modify it before the browser processes it. Inject your code into the SW script, and it runs inside the service worker scope.

This technically works. It is completely unusable for a consumer extension.

When you attach the debugger to any tab, Chrome displays a persistent banner at the top of the browser: "Chrome is being controlled by automated test software." This banner appears on every tab. It cannot be dismissed. It cannot be hidden by the extension. The only way to suppress it is to launch Chrome with --silent-debugger-extension-api, which is not something a real user would do.

For a Chrome Web Store extension that people install on their own machine, this approach would immediately look like malware. Ruled out.

Approach 3: declarativeNetRequest

Manifest V3's declarativeNetRequest API lets extensions block or redirect network requests. Could you redirect the Slack service worker script to a modified version?

No. declarativeNetRequest can block or redirect a request, but it cannot modify the response body. And even if it could redirect the service worker script URL, the replacement would need to be served from the same origin as the site — extensions can't serve content from slack.com.

What Firefox can do that Chrome can't

Here's where it gets interesting.

Firefox has an API called webRequest.filterResponseData(). It lets an extension intercept a network response and modify its body before the browser processes it. Applied to a service worker JavaScript file, you could inject code that runs inside the SW scope. That code could override self.registration.showNotification and intercept push notifications.

This capability exists in Firefox. It was advocated for by Giorgio Maone, the developer of NoScript, who needed exactly this kind of deep injection for a privacy tool.

Chrome removed blocking webRequest in MV3 and never added a filterResponseData equivalent. This is one of the more significant functional divergences between the two extension models post-MV3. Extension developers have raised it on the Chromium mailing lists. For now, it's a genuine gap.

What this means for Serious Notification

The extension works well for the constructor path — notifications fired from page JavaScript when a tab is active. For many apps and many use cases, that's most of their notification volume.

For pure push-via-service-worker notifications from backgrounded tabs — like Slack when you've minimised the window — the extension will miss them. I've added a Known Limitations section to the original article to reflect this honestly.

What would need to change for this to be solvable on Chrome? Some form of extension access to service worker scope — whether through a filtered response body API like Firefox's, or through a purpose-built notification interception hook in the Chrome Extensions API. Neither exists today.

If you want to see this change, the Chromium issue tracker is the place to make that case. I'm watching it.

In the meantime, if you want to try what's possible now:

🔗 https://chromewebstore.google.com/detail/hnaggblalhlbihfaegbknioadncpcged?utm_source=coderlegion&utm_medium=content&utm_campaign=article2-sw

How I built a Chrome extension that speaks notifications — and the two Manifest V3 problem i faced

Mon, 31 Aug 2026 09:17:48 +0000

I counted how many times I glanced at a notification during a coding session last week.

Thirty-four times. Only four needed my attention.

So I built Serious Notification — a Chrome extension that speaks browser notifications aloud, but only when they match keywords you set. Type "failed" and only hear build errors. Type "urgent" and only hear what actually matters. Everything else stays silent.

It took a weekend to build the core. The two Manifest V3 architectural problems I hit along the way took longer to figure out. Neither of them is well documented. Here's both.

Problem 1: You can't intercept the Notification API in a regular content script

The plan seemed simple: listen for notifications, check them against keywords, speak the matching ones. A content script listening for notification events should work, right?

No.

Chrome's Notification constructor lives on window. When a website calls new Notification("You have a message"), it's using window.Notification in the page's own JavaScript context.

A standard Manifest V3 content script runs in what Chrome calls an ISOLATED world — a sandboxed environment that shares the DOM with the page but has its own separate JavaScript context. Your content script can read the DOM, but it cannot touch window.Notification on the actual page. By the time your script runs, the page's Notification constructor is completely separate from anything you can reach.

You can listen for a notification after it fires. You cannot intercept it before.

The fix: MAIN world content scripts

Manifest V3 added support for content scripts that run in the MAIN world. Set "world": "MAIN" in your manifest and your script runs directly in the page's JavaScript context — before any page code executes.

{
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["interceptor.js"],
      "world": "MAIN",
      "run_at": "document_start"
    }
  ]
}

Now you can override window.Notification before the page has a chance to use it:

const OriginalNotification = window.Notification;

window.Notification = function(title, options = {}) {
  window.dispatchEvent(
    new CustomEvent('__sn_notification__', {
      detail: { title, body: options.body || '' }
    })
  );
  return new OriginalNotification(title, options);
};

The catch: MAIN world scripts have no Chrome extension APIs

Here is the problem with MAIN world scripts. They run in the page context, which means:

No chrome.storage — you cannot read the user's saved keywords
No speechSynthesis — you cannot speak the notification aloud
No extension APIs at all

You are in the page's world. Chrome's extension APIs are not available there.

So you need two scripts.

The bridge

Script 1 (interceptor.js) runs in the MAIN world. It overrides window.Notification and fires a custom DOM event when a notification arrives.

Script 2 (content.js) runs in the ISOLATED world. It has full access to chrome.storage and speechSynthesis. It listens for the custom event:

window.addEventListener('__sn_notification__', async (e) => {
  const { title, body } = e.detail;
  const data = await chrome.storage.local.get(['enabled', 'keywords', 'speed']);

  if (!data.enabled) return;

  const keywords = data.keywords || [];
  const text = `${title} ${body}`.toLowerCase();
  const match = keywords.some(kw => text.includes(kw.toLowerCase()));

  if (match || keywords.length === 0) {
    const utterance = new SpeechSynthesisUtterance(`${title}. ${body}`);
    utterance.rate = data.speed || 1.0;
    speechSynthesis.speak(utterance);
  }
});

Two scripts. One custom DOM event as the bridge. The MAIN world intercepts, the ISOLATED world decides.

Problem 2: Chrome showed a "read and change all your data on all websites" warning at install

The extension needs to inject on every page — that's legitimate, since you don't know which tab will fire a notification. So <all_urls> host access is genuinely required.

But I was declaring it as a required permission in manifest.json:

"content_scripts": [
  {
    "matches": ["<all_urls>"],
    ...
  }
]

This caused Chrome to show the scariest possible install warning before users had any reason to trust the extension. I was watching my analytics and seeing a 33% uninstall rate. Some of that was almost certainly people bouncing at the permission screen, before they ever heard the extension speak a single word.

The fix: optional host permissions

Manifest V3 supports optional_host_permissions. Move <all_urls> there instead of requiring it at install:

{
  "permissions": ["storage", "scripting"],
  "optional_host_permissions": ["<all_urls>"]
}

Then register content scripts dynamically at runtime using chrome.scripting.registerContentScripts(), only after the user explicitly grants the permission:

// background.js
chrome.permissions.onAdded.addListener(async (permissions) => {
  if (permissions.origins?.includes('<all_urls>')) {
    await chrome.scripting.registerContentScripts([
      {
        id: 'interceptor',
        matches: ['<all_urls>'],
        js: ['interceptor.js'],
        world: 'MAIN',
        runAt: 'document_start',
      },
      {
        id: 'content',
        matches: ['<all_urls>'],
        js: ['content.js'],
        runAt: 'document_start',
      }
    ]);
  }
});

In the popup, show a "Turn on to hear alerts" button that triggers the permission request:

chrome.permissions.request({ origins: ['<all_urls>'] });

The result: the Chrome Web Store install dialog now shows Storage only. No broad-access warning. The scary prompt only appears when the user explicitly clicks "Turn on" inside the popup — after they have already installed the extension and understand what it does.

One edge case: updating from a version that required the permission

When you update an extension and a previously required permission becomes optional, Chrome removes it from the user's granted set. Existing users lose host access silently on update — the extension just stops working with no explanation.

The fix: fire a native notification immediately after update using the notifications permission:

chrome.runtime.onInstalled.addListener(({ reason }) => {
  if (reason === 'update') {
    chrome.notifications.create('update-notice', {
      type: 'basic',
      iconUrl: 'icon.png',
      title: 'Serious Notification — One quick step needed',
      message: 'We improved how permissions work. Open the extension and click "Turn on" to re-enable.',
      requireInteraction: true,
    });
  }
});

Silent failure is the worst outcome for retention. If something breaks on update, tell the user immediately and tell them exactly what to do.

What I built

Serious Notification speaks Chrome notifications aloud when they match keywords you set. Free, no account, works offline. Just shipped v0.2.0 with the optional permissions model above.

If you're building Chrome extensions and hit either of these problems — happy to answer questions in the comments. The MAIN world injection in particular has some edge cases around static property copying (permission, requestPermission) that took me a while to get right.

🔗Serious Notification - Live Chrome WebStore

Known Limitations

This approach only intercepts notifications fired via the Notification constructor in the page's JavaScript context.

Notifications fired from a service worker via registration.showNotification() — which is the path used by background push notifications in apps like Slack — bypass the MAIN world override entirely. The service worker runs in its own scope and never touches the page's window.

Chrome's extension model does not currently offer a hook into arbitrary third-party service workers, so this gap cannot be closed with the current architecture.

The extension works well for in-tab notifications and apps that call the constructor directly from page scripts. For pure push-via-service-worker apps when the tab is backgrounded, it will miss notifications.

10 VS Code Extensions Every Frontend Developer Needs

Fri, 24 Jul 2026 05:00:00 +0000

Introduction

I used to install every extension that looked interesting — ended up with 40+ extensions and a VS Code that took 10 seconds just to open. Eventually I stripped it back down to the ones I actually use every single day.

These 10 are the ones that survived that cleanup. If you're setting up a fresh frontend dev environment, start here.

1. ESLint

Catches bugs and enforces consistent code style before you even run your code. If you're working in a team (or want to look like you know what you're doing), this is non-negotiable.

2. Prettier — Code Formatter

Auto-formats your code on save. No more arguing about tabs vs. spaces or where semicolons go — Prettier just decides and moves on.

Setup tip: Enable "Format on Save" in VS Code settings so it happens automatically.

3. Tailwind CSS IntelliSense

If you're using Tailwind (and you should be, per Article 3), this gives you autocomplete for class names, shows the actual CSS values on hover, and even highlights conflicting classes.

4. Auto Rename Tag

Rename an opening HTML/JSX tag and the closing tag updates automatically. Small thing, saves real time, especially in nested JSX.

5. Bracket Pair Colorizer (Built-in now)

VS Code now has this built in by default — matching brackets get color-coded so you can actually see which { belongs to which } in deeply nested code. Just make sure it's enabled in settings.

6. GitLens

Shows you who changed a line of code and when, right inline in the editor. Incredibly useful once you're working with any kind of version history — even solo projects benefit from seeing your own commit history at a glance.

7. Live Server

Spins up a local development server with live reload in one click — no need to manually refresh the browser every time you save a file. Especially useful for plain HTML/CSS/JS projects without a build tool.

8. Thunder Client

A lightweight REST API client built directly into VS Code. If you're testing an API endpoint for a project, you don't need to leave your editor or open Postman separately.

9. Error Lens

Shows error and warning messages inline, right next to the line of code causing the problem, instead of making you check the Problems panel. Cuts down debugging time noticeably.

10. Material Icon Theme

Purely visual, but genuinely useful — gives every file type a distinct, recognizable icon in your file explorer. Makes navigating a large project noticeably faster once your eyes learn the icon shapes.

How to Install Any of These

Open VS Code
Click the Extensions icon in the sidebar (or Ctrl+Shift+X)
Search the extension name
Click Install

That's it — no restart usually needed.

Final Thoughts

You don't need 40 extensions to be productive — you need the right 8 to 10. Install these, use them for a week, and you'll notice fewer small annoyances and less time spent on formatting, tag matching, and manual browser refreshing.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: muhammad-farhan-dev.github.io/muhammadfarhan.dev

website blocker Do not distracted

Sun, 07 Jun 2026 07:41:37 +0000

it locks the website only user selected website be unlock so user can focus on work.

https://chromewebstore.google.com/detail/do-not-distracted/gacffmmkpjfmepihjjhhlhleepjlmbaj

website blocker locks all the website only user selected website be unlock so user can focus on work or you can use this for the children.

How to work:- click on the extension open the extension popup click on the set password create the password and type the password and click to the ok and go to website you want to be unlock by default. goes to the website url and click to the save tab all the selected tab are become unlock all the time other website become lock if you want to open that type the right password and click to the ok that website become unlock but after removing the tab it automatic lock the website.

after creating and changing the password if the any tab is opened before setting the password refresh the page.

Do not distracted website blocker

Sun, 07 Jun 2026 07:39:02 +0000

it locks the website only user selected website be unlock so user can focus on work.

https://chromewebstore.google.com/detail/do-not-distracted/gacffmmkpjfmepihjjhhlhleepjlmbaj

website blocker locks all the website only user selected website be unlock so user can focus on work or you can use this for the children.

after creating and changing the password if the any tab is opened before setting the password refresh the page.

chrome extension Do not distracted website blocker locks all website only user selected be unlock.

Sun, 07 Jun 2026 07:36:47 +0000

it locks the website only user selected website be unlock so user can focus on work.

https://chromewebstore.google.com/detail/do-not-distracted/gacffmmkpjfmepihjjhhlhleepjlmbaj

website blocker locks all the website only user selected website be unlock so user can focus on work or you can use this for the children.

after creating and changing the password if the any tab is opened before setting the password refresh the page.

Do not distracted chrome extension locks website so can user focus on work only selected be unlock.

Sun, 31 May 2026 05:20:57 +0000

It locks all the website only user selected website be unlock so user can focus on work or you can use this for the children.

[chrome web store link to download]
[1]: https://chromewebstore.google.com/detail/do-not-distracted/gacffmmkpjfmepihjjhhlhleepjlmbaj

after creating and changing the password if the any tab is opened before setting the password refresh the page.

Your AI Chats Are Locked in Corporate Silos. I Built an Open-Source Vault to Rescue Them

Tue, 26 May 2026 19:40:20 +0000

I Kept Losing Context Switching Between AI Tools — So I Built a Browser Extension That Remembers Everything

Your AI conversations should not be trapped inside platforms.

The Problem

By 2025, most developers use multiple AI tools every day.

ChatGPT for quick questions
Claude for long reasoning
Gemini for research
Perplexity for analysis

But every platform stores conversations separately.

That creates a frustrating workflow:

Conversations get cut when context windows fill up
Switching platforms destroys continuity
Exporting chats is painful or incomplete
Your history is tied to accounts you don’t control
There’s no unified search across platforms

In short:

The knowledge you build with AI is trapped inside isolated silos.

Why Existing Solutions Didn’t Feel Right

Some tools try solving this problem, but they usually require:

Paid APIs
Backend servers
Account linking
Cloud syncing
Monthly subscriptions

I wanted something simpler.

A question kept bothering me:

What if every AI conversation stayed entirely inside the browser?

No backend. No accounts. No tracking.

The Solution: ContextVault

ContextVault is an open-source Chrome extension that captures AI conversations locally while you use platforms like:

ChatGPT
Claude
Gemini
Perplexity
Poe
DeepSeek
Grok
Microsoft Copilot

Everything stays on your machine.

No telemetry. No external storage.

How It Works

Capturing AI conversations reliably turned out to be harder than expected.

There were two major problems:

1. Every platform has a different DOM structure

Selectors, layouts, and rendering logic differ completely between ChatGPT, Claude, Gemini, and others.

2. AI responses stream in real time

Messages arrive token-by-token instead of all at once.

To solve this, ContextVault uses a 6-layer architecture:

Adapters → Capture → Stream Assembler → Background Worker → Storage → Export

1. Adapters Layer

Each platform has its own adapter implementing a shared interface:

interface LLMAdapter {
  platform: Platform
  urlPattern: RegExp
  messageContainer: string
  userSelector: string
  assistantSelector: string
}

Each adapter knows how to:

Detect the platform
Locate messages
Handle UI differences

2. Capture Layer (DOM + Network)

This is the core system.

DOM Observer

A MutationObserver watches the conversation UI in real time.

It detects:

New messages
Streaming updates
Edited content

Network Monitor

The extension also patches:

fetch
XMLHttpRequest
WebSocket

This provides early access to streaming responses directly from network traffic.

Why both?

DOM reflects exactly what the user sees
Network capture improves streaming accuracy

Using both together dramatically reduced missed messages.

3. Stream Assembler

AI responses arrive in chunks like:

"Hel"
"lo "
"world"

The Stream Assembler rebuilds complete messages while handling:

Chunk merging
Duplicate removal
Completion detection

4. Background Worker

The background worker manages:

Active sessions
Conversation lifecycle
Deduplication
Streaming updates
Conversation linking

It also prevents duplicate saves during rapid streaming events.

5. Storage Layer (IndexedDB)

Everything is stored locally using IndexedDB.

Stored data includes:

Conversations
Drafts
Settings
Projects

Each conversation stores:

Platform
Messages
Timestamps
Model information
Tags
Conversation chains

No external database is used.

6. Export Layer

Conversations can be exported as:

Markdown
ZIP archives

Example output:

## User
How do I design a secure API?

## Assistant
Start with authentication, validation, and rate limiting...

Privacy First

ContextVault was designed around one principle:

Your conversations belong to you.

So the extension:

Has no backend server
Uses no analytics or telemetry
Works fully offline
Only activates on supported AI domains
Never sends your conversations anywhere

Tech Stack

TypeScript
Manifest V3
CRXJS + Vite
IndexedDB
MutationObserver
JSZip
Vitest

Final Thoughts

AI tools are becoming part of how we think, not just how we code.

But memory between tools is still broken.

Every platform acts like a closed silo where conversations disappear the moment you switch workflows.

ContextVault is my attempt to fix that.

A lightweight browser extension that keeps your AI conversations portable, searchable, and fully yours.

Links

GitHub: https://github.com/aliabdm/ContextVault

Demo: https://context-vault-two.vercel.app/

Portfolio: https://senior-mohammad-ali.vercel.app/

LinkedIn: https://www.linkedin.com/in/mohammad-ali-abdul-wahed-1533b9171/

Do not distracted chrome extension that locks distracted website only selected website's be unlock.

Mon, 25 May 2026 16:05:26 +0000

it locks the website only user selected website be unlock so user can focus on work

It locks all the website only user selected website be unlock so user can focus on work or you can use this for the children.

after creating and changing the password if the any tab is opened before setting the password refresh the page.

[chrome web store link]
[1]: https://chromewebstore.google.com/detail/do-not-distracted/gacffmmkpjfmepihjjhhlhleepjlmbaj

Do not distracted extension

Mon, 25 May 2026 13:17:17 +0000

it locks the website only user selected website be unlock so user can focus on work

It locks all the website only user selected website be unlock so user can focus on work or you can use this for the children.

after creating and changing the password if the any tab is opened before setting the password refresh the page.

[chrome web store link]
[1]: https://chromewebstore.google.com/detail/do-not-distracted/gacffmmkpjfmepihjjhhlhleepjlmbaj

PerfLens: Web Performance Audits Beyond

Fri, 08 May 2026 12:26:58 +0000

Lighthouse is great. I use it, and I still think it is one of the most useful performance tools available to web developers.

But I wanted something closer to the way I actually debug and ship web products, so I built PerfLens.

PerfLens is a browser-first performance auditing extension that gives you live Core Web Vitals, Lighthouse-style scoring, resource diagnostics, root cause summaries, performance history, and launch evidence directly inside your browser workflow.

Install it here: https://chromewebstore.google.com/detail/perflens/gkogamlpcnneeficmcdcnnnhobnbebdc

Why I Built It

A Lighthouse report is a strong snapshot, but performance work rarely ends with one snapshot.

During real development, I usually want to know:

What is slowing this page down right now?
Which resources are heavy?
Are my Core Web Vitals healthy?
What should I fix first?

PerfLens is built for that loop.

What It Includes

PerfLens currently supports:

Core Web Vitals: LCP, FID, CLS, INP, FCP, and TTFB.
0-100 performance scoring.
Resource breakdowns by type and size.
Audits for oversized images, missing lazy loading, render-blocking scripts, large bundles, weak caching, compression gaps, and heavy CSS.
Accessibility checks for alt text, language attributes, viewport setup, headings, and form labels.
Suggestions ranked by impact, effort, and confidence.
Root cause summaries.
Framework and build detection.
Local history per URL.
Launch evidence packs with desktop/mobile audits, screenshots, videos, JSON reports, prioritized issues, and readiness status.

PerfLens vs Lighthouse

PerfLens is not trying to replace Lighthouse. Lighthouse is still excellent for standardized lab audits.

PerfLens is focused on the browser-side workflow around the audit.

Lighthouse	PerfLens
One-time baseline report	Live browser-context auditing
Standard lab diagnostics	Page-level history and trend signals
General recommendations	Suggestions ranked by impact, effort, and confidence
Separate report flow	Popup and DevTools workflow
Audit categories	Framework/build detection and root cause stories
Report export	Launch evidence packs with screenshots, videos, JSON, and readiness status

For me, the biggest difference is that PerfLens tries to move you from "this is slow" to "this is probably why, and this is what to fix next."

Fix It With AI

When an issue appears on a localhost URL, PerfLens can identify it and generate a focused prompt for Cursor, Claude, Codex, or a custom coding agent. That makes it easier to pass local audit findings directly into your coding workflow.

Final

PerfLens came from a simple idea:

Performance auditing should be closer to the browser, closer to the product, and closer to the next fix.

If you already use Lighthouse, PerfLens can sit next to it as a practical debugging and launch-readiness companion.

How I Built and Published a VS Code Extension to the Marketplace

Sat, 02 May 2026 21:36:11 +0000

Introduction

I recently built Q Log Session Viewer — a VS Code extension that reads Amazon Q chat history and debug logs from your local machine and displays them in a browsable, filterable UI right inside VS Code. In this post I'll walk through every step: scaffolding the project, writing the extension code, packaging it, and publishing it to the VS Code Marketplace.

By the end you'll have a clear mental model of how VS Code extensions work and a repeatable process for publishing your own.

What We're Building

The extension adds an Activity Bar icon (sidebar panel) and a full editor panel that reads:

~/.aws/amazonq/history/chat-history-*.json — Amazon Q chat history
%APPDATA%\Code\logs\...\Amazon Q Logs.log — VS Code extension host logs

It parses those files and renders sessions as cards, with drill-down into individual log entries.

Sessions overview — chat history and log sessions shown as cards

Entry detail view — filter by category, search, and inspect full JSON

Prerequisites

Before starting, install:

Node.js 18+
VS Code
The Yeoman scaffolder and VS Code extension generator (optional but helpful):

npm install -g yo generator-code

Step 1 — Scaffold the Project

Run the Yeoman generator and answer the prompts:

yo code

Choose:

New Extension (TypeScript)
Name: q-log-session-viewer
Identifier: q-log-session-viewer
Description: View and analyze local Q-related debug logs and chat history from VS Code
Initialize git: Yes
Bundle with webpack/esbuild: esbuild (faster builds)

Tip: If you prefer to skip Yeoman, just create the folder structure manually. The generator only saves a few minutes.

The generated structure looks like this:

q-log-session-viewer/
├── src/
│   └── extension.ts        ← entry point
├── resources/              ← icons, screenshots
├── .vscodeignore
├── esbuild.js
├── package.json
└── tsconfig.json

Step 2 — Configure `package.json`

package.json is the heart of a VS Code extension. It declares commands, views, menus, and metadata that VS Code reads at install time.

Here is the full package.json for this extension:

{
  "name": "q-log-session-viewer",
  "displayName": "Q Log Session Viewer (Unofficial)",
  "description": "View and analyze local Q-related debug logs and chat history from VS Code",
  "version": "0.1.1",
  "publisher": "SiddheshPrabhugaonkar",
  "author": {
    "name": "Siddhesh Prabhugankar",
    "url": "https://github.com/siddheshp"
  },
  "license": "MIT",
  "icon": "resources/icon.png",
  "galleryBanner": { "color": "#232F3E", "theme": "dark" },
  "engines": { "vscode": "^1.85.0" },
  "categories": ["Debuggers", "Other"],
  "keywords": ["logs", "debug", "chat", "viewer", "analysis"],
  "activationEvents": [],
  "main": "./out/extension.js",
  "contributes": {
    "commands": [
      {
        "command": "amazonq-logviewer.open",
        "title": "Q Log Session Viewer: Open",
        "icon": {
          "light": "resources/icon-sidebar-light.svg",
          "dark": "resources/icon-sidebar-dark.svg"
        }
      },
      {
        "command": "amazonq-logviewer.refresh",
        "title": "Q Log Session Viewer: Refresh",
        "icon": "$(refresh)"
      }
    ],
    "viewsContainers": {
      "activitybar": [
        {
          "id": "amazonq-logviewer",
          "title": "Q Logs",
          "icon": "resources/icon-sidebar-dark.svg"
        }
      ]
    },
    "views": {
      "amazonq-logviewer": [
        {
          "type": "webview",
          "id": "amazonq-logviewer.viewer",
          "name": "Log Viewer"
        }
      ]
    },
    "menus": {
      "editor/title": [
        { "command": "amazonq-logviewer.open", "group": "navigation" }
      ]
    }
  },
  "scripts": {
    "vscode:prepublish": "npm run compile",
    "compile": "node esbuild.js",
    "watch": "node esbuild.js --watch",
    "package": "vsce package"
  },
  "devDependencies": {
    "@types/node": "^20.11.0",
    "@types/vscode": "^1.85.0",
    "@vscode/vsce": "^3.9.1",
    "esbuild": "^0.20.0",
    "sharp": "^0.34.5",
    "typescript": "^5.3.0"
  }
}

Key things to understand:

Field	Purpose
`publisher`	Must match your Marketplace publisher ID exactly
`engines.vscode`	Minimum VS Code version required
`activationEvents: []`	With modern VS Code, contributed commands/views can activate the extension when used
`contributes.viewsContainers`	Registers the Activity Bar icon
`contributes.views`	Registers the webview panel inside the sidebar
`vscode:prepublish`	Script that runs before `vsce package`

Step 3 — Set Up esbuild

Instead of the default tsc compiler, this extension uses esbuild for fast bundling. Create esbuild.js:

const esbuild = require('esbuild');

const watch = process.argv.includes('--watch');

const buildOptions = {
  entryPoints: ['src/extension.ts'],
  bundle: true,
  outfile: 'out/extension.js',
  external: ['vscode'],          // vscode is provided by the host, never bundle it
  format: 'cjs',
  platform: 'node',
  target: 'node18',
  sourcemap: true,
  minify: !watch,
};

if (watch) {
  esbuild.context(buildOptions).then(ctx => {
    ctx.watch();
    console.log('Watching for changes...');
  });
} else {
  esbuild.build(buildOptions).then(() => console.log('Build complete'));
}

Important: Always add vscode to external. It is injected by VS Code at runtime and must never be bundled.

Step 4 — Write the Extension Entry Point

src/extension.ts is the file VS Code calls when the extension activates. It registers commands and the sidebar webview provider:

import * as vscode from 'vscode';
import { LogViewerPanel, LogViewerSidebarProvider } from './logViewerPanel';

export function activate(context: vscode.ExtensionContext) {
  // Register the sidebar webview (Activity Bar panel)
  const sidebarProvider = new LogViewerSidebarProvider(context.extensionUri);
  context.subscriptions.push(
    vscode.window.registerWebviewViewProvider('amazonq-logviewer.viewer', sidebarProvider)
  );

  // Command: open full editor panel
  context.subscriptions.push(
    vscode.commands.registerCommand('amazonq-logviewer.open', () => {
      LogViewerPanel.createOrShow(context.extensionUri);
    })
  );

  // Command: refresh data
  context.subscriptions.push(
    vscode.commands.registerCommand('amazonq-logviewer.refresh', () => {
      LogViewerPanel.currentPanel?.refresh();
      sidebarProvider.refresh();
    })
  );
}

export function deactivate() {}

Two patterns to note:

Push to context.subscriptions — VS Code automatically disposes these when the extension deactivates, preventing memory leaks.
deactivate() — called when VS Code shuts down or the extension is disabled. Leave it empty if you have nothing to clean up.

Step 5 — Read Local Log Files (`logProvider.ts`)

This class handles all filesystem access. It resolves the correct log paths per OS:

import * as fs from 'fs';
import * as path from 'path';
import * as os from 'os';

export class LogProvider {
  private logBase: string;
  private historyDir: string;

  constructor() {
    const home = os.homedir();
    const platform = os.platform();

    if (platform === 'win32') {
      const appdata = process.env.APPDATA || path.join(home, 'AppData', 'Roaming');
      this.logBase = path.join(appdata, 'Code', 'logs');
    } else if (platform === 'darwin') {
      this.logBase = path.join(home, 'Library', 'Application Support', 'Code', 'logs');
    } else {
      this.logBase = path.join(home, '.config', 'Code', 'logs');
    }

    this.historyDir = path.join(home, '.aws', 'amazonq', 'history');
  }

  // ... getSessionLogs() and getChatHistoryFiles() methods
}

Log paths by OS:

OS	Extension Logs	Chat History
Windows	`%APPDATA%\Code\logs\...\Amazon Q Logs.log`	`~\.aws\amazonq\history\`
macOS	`~/Library/Application Support/Code/logs/...`	`~/.aws/amazonq/history/`
Linux	`~/.config/Code/logs/...`	`~/.aws/amazonq/history/`

Step 6 — Build the Webview Panel (`logViewerPanel.ts`)

VS Code extensions can render arbitrary HTML inside WebviewPanel (full editor tab) or WebviewView (sidebar). Both are used here.

Security: Content Security Policy + Nonce

Every webview must set a strict CSP. A nonce (random string per render) is used to allow only your inline scripts:

function getNonce(): string {
  let text = '';
  const possible = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
  for (let i = 0; i < 32; i++) {
    text += possible.charAt(Math.floor(Math.random() * possible.length));
  }
  return text;
}

The CSP meta tag in the HTML:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'none';
           style-src 'nonce-${nonce}';
           script-src 'nonce-${nonce}';">

Two-Way Messaging

The webview and extension communicate via postMessage:

// Extension → Webview: send data
panel.webview.postMessage({ command: 'dataLoaded', historyFiles, logSessions });

// Webview → Extension: request data
panel.webview.onDidReceiveMessage(message => {
  if (message.command === 'loadData') {
    const data = logProvider.loadAllData();
    panel.webview.postMessage({ command: 'dataLoaded', ...data });
  }
});

Inside the webview HTML:

const vscode = acquireVsCodeApi();

// Send message to extension
vscode.postMessage({ command: 'loadData' });

// Receive message from extension
window.addEventListener('message', event => {
  if (event.data.command === 'dataLoaded') {
    renderSessions(event.data.historyFiles, event.data.logSessions);
  }
});

export class LogViewerSidebarProvider implements vscode.WebviewViewProvider {
  resolveWebviewView(webviewView: vscode.WebviewView, ...) {
    webviewView.webview.options = {
      enableScripts: true,
      localResourceRoots: [vscode.Uri.joinPath(this._extensionUri, 'resources')]
    };
    webviewView.webview.html = getViewerHtml(getNonce());
    // ... message handler
  }
}

Step 7 — Add Icons

VS Code requires icons in specific formats:

Marketplace icon: resources/icon.png — 128×128 PNG, referenced in package.json as "icon"
Activity Bar icon: SVG file — VS Code tints it automatically to match the theme; keep it a simple monochrome shape

"viewsContainers": {
  "activitybar": [
    {
      "id": "amazonq-logviewer",
      "title": "Q Logs",
      "icon": "resources/icon-sidebar-dark.svg"
    }
  ]
}

Gotcha: Activity Bar icons are always rendered as monochrome by VS Code regardless of the SVG colors. Design them as single-color silhouettes.

Step 8 — Configure `.vscodeignore`

.vscodeignore works like .gitignore but for the packaged .vsix file. Exclude everything that isn't needed at runtime:

.vscode/**
node_modules/**
src/**
esbuild.js
tsconfig.json
**/*.map
**/*-b64.txt
resources/screenshots/*.png

Keep in the package:

out/extension.js (compiled bundle)
resources/ (icons used by the extension)
package.json
README.md
LICENSE

Step 9 — Test Locally

Press F5 in VS Code to launch the Extension Development Host — a second VS Code window with your extension loaded.

You'll see the Q Logs icon appear in the Activity Bar:

Iterate quickly with:

npm run watch

esbuild rebuilds in milliseconds on every save. Reload the Extension Development Host with Ctrl+R (or Cmd+R on Mac) to pick up changes.

Step 10 — Package the Extension

Install vsce (the VS Code Extension CLI) if you haven't already:

npm install -g @vscode/vsce

Then package:

vsce package

This produces a .vsix file (e.g. q-log-session-viewer-0.1.1.vsix). You can install it locally to test the final artifact:

code --install-extension q-log-session-viewer-0.1.1.vsix

Step 11 — Create a Publisher Account

Go to https://marketplace.visualstudio.com/manage
Sign in with a Microsoft account
Click Create publisher
Choose a publisher ID (e.g. SiddheshPrabhugaonkar) — this must match the "publisher" field in package.json exactly

You also need a Personal Access Token (PAT):

Go to https://dev.azure.com → your organization → User Settings → Personal Access Tokens
Click New Token
Set scope to Marketplace → Manage
Copy the token — you won't see it again

Authenticate vsce with your token:

vsce login SiddheshPrabhugaonkar
# Paste your PAT when prompted

Step 12 — Write a Good README

The README.md in your extension folder becomes the Marketplace listing page. Make it count:

Lead with what the extension does and who it's for
Include screenshots (host them on GitHub or a CDN — relative paths don't work on the Marketplace)
List features, commands, and requirements
Add a disclaimer if your extension reads data from another product

Screenshot URLs must be absolute:

![Sessions View](https://raw.githubusercontent.com/youruser/your-assets-repo/main/screenshots/sessions-view.png)

Tip: Create a separate public GitHub repo just for assets (screenshots, GIFs). This keeps your extension repo clean and the URLs stable.

Step 13 — Publish to the Marketplace

vsce publish

That's it. vsce will:

Run npm run vscode:prepublish (which runs npm run compile)
Package the .vsix
Upload it to the Marketplace

To publish a specific version bump:

vsce publish patch   # 0.1.0 → 0.1.1
vsce publish minor   # 0.1.0 → 0.2.0
vsce publish major   # 0.1.0 → 1.0.0

After a few minutes your extension appears at: https://marketplace.visualstudio.com/items?itemName=SiddheshPrabhugaonkar.q-log-session-viewer

Step 14 — Update the Extension

For subsequent releases:

Make your code changes
Update CHANGELOG / release notes in README.md
Run vsce publish patch (or minor/major)

The Marketplace auto-notifies users who have the extension installed.

Project File Structure (Final)

VSCodeExtention/
├── resources/
│   ├── icon.png                  ← Marketplace icon (128×128 PNG)
│   ├── icon-sidebar-dark.svg     ← Activity Bar icon
│   └── icon-sidebar-light.svg
├── src/
│   ├── extension.ts              ← activate() / deactivate()
│   ├── logProvider.ts            ← filesystem reads
│   └── logViewerPanel.ts         ← WebviewPanel + WebviewView + HTML
├── .vscodeignore
├── esbuild.js
├── package.json
├── tsconfig.json
└── README.md

Key Concepts Recap

Concept	What it does
`contributes.viewsContainers`	Adds an icon to the Activity Bar
`contributes.views`	Registers a panel inside that container
`WebviewPanel`	Full editor tab with custom HTML
`WebviewViewProvider`	Sidebar panel with custom HTML
`postMessage` / `onDidReceiveMessage`	Two-way communication between extension and webview
Nonce + CSP	Security: prevents XSS in webviews
`context.subscriptions`	Automatic cleanup on deactivation
`vsce package`	Creates the installable `.vsix`
`vsce publish`	Uploads to the VS Code Marketplace

Common Gotchas

vscode must be in external in your bundler config — never bundle it
Marketplace icon must be PNG, not SVG
Screenshot URLs in README must be absolute — relative paths break on the Marketplace page
Publisher ID in package.json must exactly match your Marketplace publisher account
Activity Bar SVG icons are always monochrome — VS Code tints them; don't rely on color
CSP default-src 'none' — be explicit about what your webview is allowed to load; no external CDNs unless you add them to the CSP

Resources

Built by Siddhesh Prabhugankar — Microsoft Certified Trainer & AI Consultant
GitHub: github.com/siddheshp · LinkedIn: linkedin.com/in/siddheshprabhugaonkar

How GitHub Copilot Helped Me Roast Its Own Users

Sun, 08 Feb 2026 07:19:53 +0000

What if GitHub Copilot didn’t just help you write code but judged you for it?

What I Built

I had been waiting for a challenge that truly sounded like me for a long time, and that’s when the GitHub Copilot CLI Challenge showed up.

Within five minutes, the idea that popped into my head was to use Copilot CLI to do something with Copilot itself.

That’s when the idea of roasting the user for their GitHub Copilot usage came up.

Then I started wondering how to implement it.

Whether to build something that runs in the terminal but that would consume RAM.

Should I try a different approach?

That’s when the idea of a VS Code extension popped up (GitHub CLI actually helped me there ).

This was my first time using an AI pair programmer to help me build a project completely, because I had never built, or even thought about creating a VS Code extension before.

The roasts are static for now and don’t use AI, because I couldn’t afford an API key .

Demo

Click the following link:
Copilot Roaster Extension

Install the extension using the link.

And your setup is complete.

Then, open any sample file to test it.

Ask GitHub Copilot to write something and accept its suggestion to see the magic ✨

Find my demo below:

Demo

You can find the GitHub repository here.

Feel free to fork, modify, and upgrade it.

My Experience with GitHub Copilot CLI

This was my first time using an AI pair programmer in the CLI. I was really excited to see how it worked. After installing it and typing copilot in the terminal, it felt like magic when this showed up.

I started wondering how it would work, which subscription it would use and which profile it would be linked to.

While thinking about all this, I typed a prompt, and that’s when I got an error saying I needed to log in to proceed further.

First, we need to use /login to sign in with our GitHub account.

After that, everything was smooth. The suggestions were almost exactly what I expected (maybe my prompt was too good ).

Then I tweaked things a bit, and tadaaa

The extension was ready and looked cool.

I added a few more roasts just to make sure the same ones didn’t repeat.

Then I published it on the Marketplace.

GitHub Copilot CLI provided me with the exact steps to publish the extension, because I had no clue how to do it and the whole process was smooth as well.

So go ahead, install the extension, let Copilot write your code, and brace yourself… because this time, you’re the one getting reviewed

Follow me on Linkedin | GitHub | Twitter

Subscribe to my newsletter and get articles delivered straight to your inbox.

Coder Legion - Recent posts tagged extension

🚀 Managing MCP Servers in VS Code? Explore SEOSiri MCP Suite Manager!

MCP #ModelContextProtocol #VSCode #AIDevelopment #DeveloperTools #SEOSiri

Vue.js Web Browser Extension Template

api-performance-profiler

Trying to intercept Slack push notifications from a Chrome extension. Here's why it's Impossible

How I built a Chrome extension that speaks notifications — and the two Manifest V3 problem i faced

Known Limitations

10 VS Code Extensions Every Frontend Developer Needs

Introduction

1. ESLint

2. Prettier — Code Formatter

3. Tailwind CSS IntelliSense

4. Auto Rename Tag

5. Bracket Pair Colorizer (Built-in now)

6. GitLens

7. Live Server

8. Thunder Client

9. Error Lens

10. Material Icon Theme

Final Thoughts

website blocker Do not distracted

Do not distracted website blocker

chrome extension Do not distracted website blocker locks all website only user selected be unlock.

Do not distracted chrome extension locks website so can user focus on work only selected be unlock.

Your AI Chats Are Locked in Corporate Silos. I Built an Open-Source Vault to Rescue Them

I Kept Losing Context Switching Between AI Tools — So I Built a Browser Extension That Remembers Everything

The Problem

Why Existing Solutions Didn’t Feel Right

The Solution: ContextVault

How It Works

1. Every platform has a different DOM structure

2. AI responses stream in real time

1. Adapters Layer

2. Capture Layer (DOM + Network)

DOM Observer

Network Monitor

Why both?

3. Stream Assembler

4. Background Worker

5. Storage Layer (IndexedDB)

6. Export Layer

Privacy First

Tech Stack

Final Thoughts

Links

Do not distracted chrome extension that locks distracted website only selected website's be unlock.

Do not distracted extension

PerfLens: Web Performance Audits Beyond

Why I Built It

What It Includes

PerfLens vs Lighthouse

Fix It With AI

Final

How I Built and Published a VS Code Extension to the Marketplace

Introduction

What We're Building

Prerequisites

Step 1 — Scaffold the Project

Step 2 — Configure package.json

Step 3 — Set Up esbuild

Step 4 — Write the Extension Entry Point

Step 5 — Read Local Log Files (logProvider.ts)

Step 6 — Build the Webview Panel (logViewerPanel.ts)

Security: Content Security Policy + Nonce

Two-Way Messaging

Sidebar Provider

Step 7 — Add Icons

Step 8 — Configure .vscodeignore

Step 9 — Test Locally

Step 10 — Package the Extension

Step 11 — Create a Publisher Account

Step 12 — Write a Good README

Step 13 — Publish to the Marketplace

Step 14 — Update the Extension

Project File Structure (Final)

Key Concepts Recap

Common Gotchas

Resources

How GitHub Copilot Helped Me Roast Its Own Users

Step 2 — Configure `package.json`

Step 5 — Read Local Log Files (`logProvider.ts`)

Step 6 — Build the Webview Panel (`logViewerPanel.ts`)

Step 8 — Configure `.vscodeignore`