Replit Agent 4 built my Chrome extension. Here is what it got wrong.

The brief I gave Replit Agent 4 was one paragraph:

"Build a Chrome extension that shows all open tabs grouped by domain, lets me search across tab titles, and has a button to close all tabs from a specific domain at once. Use Manifest V3."

Agent 4 started immediately. It created a project with the manifest file, a popup HTML page, a background service worker, and a content script. Eight minutes later it had a working extension that I could load via chrome://extensions in developer mode. The tab grouping worked, the search worked, and the close-by-domain button worked.

Then I tried to submit it to the Chrome Web Store and everything fell apart.

Problem 1: the permissions model

Agent 4 declared the tabs, activeTab, storage, and <all_urls> permissions in the manifest. The Chrome Web Store review process flagged <all_urls> as a broad host permission requiring justification. The extension does not need access to page content on any URL. It only needs the tabs API to list open tabs. The <all_urls> permission was unnecessary and would have caused the review to take weeks instead of days.

The fix was simple: remove <all_urls> and the content script entirely. The extension only needs tabs and activeTab. Agent 4 included the content script and broad permissions because it was pattern-matching from examples that did need page access, not reasoning about what this specific extension requires.

Problem 2: the Manifest V3 service worker

Agent 4 wrote the background script as a persistent service worker. In Manifest V3, service workers are not persistent. They wake on events and shut down after 30 seconds of inactivity. The code worked in development because Chrome keeps service workers alive while DevTools is open, which masks the problem.

In production, the service worker would shut down between user interactions, losing any in-memory state. Agent 4 had stored the tab grouping state in a JavaScript variable. When the service worker restarted, the state was gone. The fix was moving the state to chrome.storage.session and reading it on each wake, which took about 20 minutes to refactor.

This is a genuinely tricky bug because it only manifests when the extension is installed normally (not in developer mode with DevTools open). Agent 4 cannot test in that environment, so it has no way to catch this class of failure.

Problem 3: Chrome Web Store assets

The Chrome Web Store requires specific screenshot sizes (1280x800 or 640x400), a 128x128 icon, a promotional tile (440x280), and a detailed description. Agent 4 generated a 48x48 icon (the minimum for the manifest) and nothing else. I had to create the remaining assets manually.

This is a minor issue but it added 30 minutes of work. A better prompt might have asked Agent 4 to generate the store listing assets as part of the project, but even then, AI-generated screenshots of a Chrome extension popup are unlikely to match what the actual extension looks like.

What Agent 4 got right

The core functionality was correct and well-structured. The popup UI used clean HTML and CSS with no framework, which is the right choice for a Chrome extension popup. The tab search was implemented with a debounced input handler that filtered the tab list client-side, which is the correct approach for performance. The domain grouping logic correctly handled subdomains by grouping on the root domain.

Agent 4 also correctly configured the action field in the manifest (the popup trigger), set the default icon sizes, and included a reasonable CSP header. The boilerplate was right. The architecture decisions were right. The failures were all in the details that require runtime testing in Chrome's extension environment.

The pattern

Replit Agent 4 is excellent at scaffolding. It generates correct project structure, sensible architecture, and working core logic faster than I could write it from scratch. It fails on environmental constraints that it cannot test: Chrome extension lifecycle behaviour, App Store submission requirements, browser-specific API quirks, and permissions models that only matter at review time.

The right workflow is to use Agent 4 for the first 80% (structure, UI, core logic) and then switch to manual development or to Claude for the remaining 20% (permissions audit, lifecycle testing, store preparation). If I had paired Agent 4's output with a Claude review prompt ("audit this Chrome extension manifest for unnecessary permissions and Manifest V3 lifecycle issues"), I would have caught problems 1 and 2 before spending time on manual debugging.

Agent 4's parallel task execution is a nice improvement over earlier versions. It generated the popup, background script, and manifest concurrently rather than sequentially, which is why the initial generation was so fast. For a Chrome extension this is a small benefit. For a larger project with multiple independent modules, the parallelism would save more time.