Claude Released Something To Fix Your Errors

The way our team builds our apps has been significantly improved. The reason Claude Code recently launched its Chrome extension. You might think this was already possible with the Playright or Puppeteer MCP. But those tools had serious problems like an unnecessarily bloated context window, a messed up project folder filled with random screenshots, and most of the time they couldn't even complete the actions on the app. This is why I was never a huge advocate of automated testing using AI. But this is also why I was really excited about this new Claude extension. If you've been keeping up with the channel, you might know that we actually made a video on it some time ago. The funny thing is that it wasn't meant for Claude Code, but we clearly said that this extension has way more potential if it was. And here we are. Now, it's finally out as an integrated MCP, and it gives Claude Code all the custom tools it needs. Now, right out of the box, it has some huge problems that we should fix. But before we dive into those, let's take a quick break to talk about Automata. After teaching millions of people how to build with AI, we started implementing these workflows ourselves. We discovered we could build better products faster than ever before. We help bring your ideas to life, whether it's apps or websites. Maybe you've watched our videos thinking, "I have a great idea, but I don't have a tech team to build it." That's exactly where we come in. Think of us as your technical co-pilot. We apply the same workflows we've taught millions directly to your project, turning concepts into real working solutions without the headaches of hiring or managing a dev team. Ready to accelerate your idea into reality? reach out at hello@automator.dev. Coming back to the problems, the biggest one I faced was that it took too many sequential steps to just test something really simple. You might have noticed that when you ask Claude to visually test a website's landing page, it performs a scroll operation for each section and captures a screenshot at every step. It then stitches all the screenshots together to analyze the UI section by section. You might think this is a good approach, but it's not. Instead of this, we can make it take full page screenshot and save all those tokens. To solve this, I used a script that leverages different web tools to take the full shots. I also added instructions to use that script in a custom/comand in my project. Now, when I use that command to test the landing page, it recognizes that this is a full page test based on the instructions I've included and uses the script directly instead of the usual section bysection method. Because of this, the test happens significantly faster and it has the same accuracy. The second problem I encountered was when these MCP tools tried to load a huge amount of content all at once for a simple task. Instead of loading specific divs, it often loads all the HTML within the main tag, which contains a huge amount of tokens, even when it's not necessary. This ends up consuming a large chunk of the context window, and even your simplest tasks can bloat it significantly. To solve this, I added instructions in the claude.md file on how to properly manage context when using the Claude Chrome extension. This way any extraction is precisely limited and it doesn't bloat the context with unnecessary information. Another problem is that Claude wastes a lot of time when it encounters websites that contain unwanted pop-ups such as cookie notices and similar prompts. To get rid of them, it uses the same screenshot and scroll sequences. But this is wrong. Instead of letting Claude consume unnecessary tokens and time, we can use other workarounds to handle these pop-ups. As an alternative, I created a script that includes the most common accept button selectors and patterns for dismissing cookie banners. It finds those selectors in the code and executes functions to dismiss the pop-ups automatically. I also added instructions in the claude.md file. So, it runs this script first before proceeding with the main content. Now, whenever I ask Claude to go to a website, it first follows the instructions in claude.md and executes this JavaScript. This automatically dismisses the cookie banners, allowing Claude to continue with the main content without wasting any tokens or performing unnecessary steps. For security reasons, Claude has been limited from performing captures or completing authentication on your behalf. So, if you come across a website that contains them, Claude can't complete this process for you. This is something you have to handle on your own. Whenever you work on a website that requires login or capture verification, make sure you've already authenticated before giving Claude the task. This way it won't get blocked and waste any time. So these were the main problems I could solve. But to properly use it for testing, you actually need a proper workflow to test out any application. But before we get to that, I want to talk a little more about why I prefer the Claude Chrome integration over Puppeteer. This is mainly because it's a native tool built by the developers of Claude Code themselves, and it offers much better integration with improved control and features. These MCPS are focused on testing in a dedicated separate environment that maintains no sessions. They're often troublesome to install and clutter your project folder with all the screenshots. On the other hand, with this new Chrome integration, Claude has the ability to interact with your signed accounts. It can interact with services like Google Docs and Google Sheets. It can even retain all session information and use it to perform tasks even better. Before we get to the workflow, I want to mention that browser integrations do use a lot of context because they're just more compute inensive than regular tool calls. They've even mentioned it in one of their blogs. So, you do need to keep an eye on the autoco compaction while working with claw code. Also, since this is the Chrome integration, it only works with Chrome. I expected it would work with any Chromium browser, but it doesn't. And we can't really solve that. And for those of us that use multiple Chrome profiles, it'll be a little more frustrating because it continuously opens up the wrong profiles. And I do hope they solve this bug pretty soon. With all the fixes I mentioned earlier and the integration of Claude with Chrome, my development workflow has improved significantly. However, Chrome extensions have a limitation in manifest v3. They can be blocked if they run for too long. Many people are asking the developers of Claude Code to fix this on their repo as well. If you're doing endtoend testing of your web application from start to finish, this can cause the session to be blocked by Chrome and Claude will stop unexpectedly. You'd then have to reprompt it to restart execution. This can be particularly troublesome if you assign a long-running task to Claude and step away from your computer only to return and find the task only partially completed. For this exact reason, instead of end-to-end testing, I created multiple test files covering all different aspects of the application. Each file contains detailed information on priority levels, preconditions, testing steps, and expected results. There's also a testing guide on how to conduct these tests along with a readme for the test documentation. As you know, Claude has a limited context window, and when that limit is reached, instructions and progress can be lost. For this reason, I added instructions in the claude.md file that tell Claude to create a comprehensive test report document after testing each file. This way, even if you have to compact because the browser tools consume a lot of context, Claude can retain awareness of what's been tested and what still needs testing by referring to these progress files. Now, before progressing with any test, the best practice is to run a compact because testing your application using Chrome is going to consume a lot of your context window. To streamline my testing process, I created another custom/comand. What this command does is test in a guided manner and create documentation in a proper structure after testing following the claude.md instructions. I also added instructions to monitor the context before starting any task so that when testing begins, it doesn't lose context midway in compact while it's working. This way, when you start the testing process, you just use the slash command and provide the file you want to begin testing with and Claude starts testing by following the exact instructions. It identifies issues on its own and uses the browser and all the necessary tools for testing. It interacts with elements automatically and is able to find errors that are not usually visible but can be detected by reading the console output. It also documents the testing at the end as instructed. In this way, the entire testing process is significantly improved because Claude has access to console logs and can perform automated testing in the browser more effectively than ever before. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this, you can do so by using the super thanks button below. As always, thank you for watching and I'll see you in the next one.