Claude in Chrome Not Working? A Practical Troubleshooting Guide

Getting Stuck on Login or Authentication

The form gets filled in correctly, but after submitting, Claude can't proceed to the authenticated area. Or the session expires mid-task.

Main causes:

Two-factor authentication (2FA) is the most common blocker — Claude in Chrome cannot complete authentication app codes, SMS codes, or hardware key prompts. SSO redirects through identity providers (Okta, Google, Microsoft) can also stall the workflow. And for longer-running tasks, session cookies sometimes expire before the task finishes.

What to try:

For services with 2FA, log in manually in your browser before starting the Claude in Chrome task. The existing session is inherited, so Claude can proceed from an already-authenticated state without needing to handle credentials.

For session expiry, add a health check at the beginning of your prompt: "first verify I'm logged into [service name] by checking whether my account name is visible. If I appear to be logged out, navigate to the login page and log in." This catches session issues before they derail the main task.

A practical tip: keep your most-used service tabs open and logged in before starting Claude in Chrome tasks. This is especially helpful for automation that runs across multiple sites.

Stopped by a CAPTCHA

Claude in Chrome cannot solve CAPTCHAs. This is a deliberate design limitation, not a bug.

Practical workarounds:

For Google services, being logged into your Google account before running tasks significantly reduces CAPTCHA frequency — Google uses account reputation to decide when to skip the challenge. For other services, having an existing browser session with valid cookies often bypasses CAPTCHAs as well, since you've already demonstrated human-like behavior.

If a service consistently presents CAPTCHAs mid-task, it's actively detecting automation. At that point, fully automated Claude in Chrome operation probably isn't the right tool — consider whether a manual-assisted workflow or an official API integration would serve better.

One pattern that works well: use Claude in Chrome for the decision-making and navigation logic, and pause at CAPTCHA steps for manual intervention. You can structure your prompt to ask Claude to "stop and report back if it encounters a CAPTCHA."

Can't Read PDFs or Dynamically Generated Content

Asking Claude to read a web-based PDF or extract data from a JavaScript-rendered chart fails to return useful results.

For PDFs:

Browser-embedded PDF viewers don't expose their text through the DOM in a way Claude can reliably access — the viewer renders the PDF as a canvas or image layer, not as selectable text. The practical workaround: ask Claude to copy the PDF's URL from the address bar, then paste that URL into a Claude.ai chat window and upload the file there. Claude's native PDF parsing is much more reliable than DOM-based extraction.

For dynamically loaded content:

API-fetched data isn't in the page's initial HTML. If Claude is reading the page source rather than the rendered result, it'll miss this content entirely. Try asking Claude to "read only the text currently visible on screen, not the page source." This forces it to work from the visual rendering rather than the DOM.

For visual data like charts and graphs, the screenshot approach often works better than structured extraction: "take a screenshot of the chart and describe what you see." Claude can then interpret the visual information and summarize it — which is more reliable than trying to parse SVG elements or canvas data.

Task Stops Midway or Ends With an Error

Multi-step tasks sometimes halt partway through without completing, often with a vague error message or no message at all.

Context overflow:

Long sessions accumulate context — conversation history, page contents, screenshots — and can hit the context window limit. When this happens, Claude typically stops or produces degraded results. The fix is to break large tasks into smaller chunks: "process URLs 1 through 10" in one session, "process URLs 11 through 20" in the next. This keeps each session well within limits and makes failures easier to resume.

Network timeouts:

Slow-loading pages can cause timeouts that interrupt the task flow. Adding "if the page times out, wait 10 seconds and try again" to your prompt gives Claude permission to retry automatically rather than stopping.

Checking whether it's really Claude's fault:

Before debugging your prompt, open the target page in your browser manually. If the page is down, returning 403 errors, or behaving strangely for regular users, that's a service-side problem. Claude in Chrome will fail in the same way humans would.

Task Completes But Results Are Wrong

Claude reports success, but the actual outcome isn't what you expected.

Common examples:

Form data was entered but the save button was never clicked. Only the first page of results was processed, not all of them. Items that don't match your filter criteria were included anyway. Or Claude misinterpreted "delete all" as "delete the selected items."

What to try:

Add explicit verification steps to your prompt: "after saving the form, confirm you see a success message. If not, try submitting again." This catches the failure case where Claude thinks it succeeded but the action didn't actually go through.

For multi-page processing, define your exit condition clearly: "continue clicking 'Next page' until the button is grayed out or disappears, then stop and report the total count." Without an explicit end condition, Claude may stop at the first page or loop indefinitely.

For filtering tasks, describe the acceptance criteria: "only process items where the status shows 'Active' — skip anything else and include a count of skipped items in your report." Explicit criteria leave less room for ambiguity.

This "reported success, changed nothing" failure shows up in web monitoring too. I wrote up how to isolate it in the two weeks my web monitor said everything was fine.

MCP Server Connection Errors

If you're using Claude in Chrome alongside Cowork's MCP integrations, connection errors can appear when the server isn't reachable.

Check the Cowork settings panel first — if the MCP server shows as "Disconnected," restarting the Cowork app resolves this in most cases. If it doesn't, run the MCP server from your terminal to see its logs directly. The two most common issues are port conflicts (another process using the same port) and missing environment variables that the server expects at startup.

For persistent connection issues, double-check that your firewall isn't blocking the MCP server's port, and verify the server process is actually running before starting the Claude in Chrome session.

Isolating the Cause in Five Steps

Rewriting the whole prompt is tempting, and almost always slower than finding the layer that broke. Here is the order I work through.

1. Do the same action by hand. Does the page open, does the button respond, does the login go through? If it fails here, the service is the problem and no prompt will fix it.
2. Cut the task down to one step. Replace "log in, open the report page, download the CSV" with "open the report page and read me the column headers." This pins down exactly which step breaks.
3. Insert a wait before the failing step. If "wait 5 seconds before clicking" fixes it, the cause was timing. If it doesn't, the cause is DOM structure or permissions.
4. Switch to the visual path. Ask Claude to "take a screenshot and list the labels of every button you can see." Elements Claude cannot perceive reveal themselves here.
5. Make the verification permanent. Once the prompt works, append: "after the action, confirm the success message is visible. If it isn't, stop and report."

Skipping steps 3 and 4 to rewrite the whole prompt feels faster. In my experience it mostly trades one failure for a different one.

What the Docs Don't Tell You

Here is what three weeks and 42 runs taught me. The task: pull the weekly report from the AdMob console, and read the sales screen in App Store Connect.

Three seconds isn't enough for some screens. A plain page settles in three seconds. The AdMob console, which paints its charts asynchronously, did not — Claude read an empty table. Stretching the wait to six seconds took empty reads from a recurring annoyance to zero across twelve runs. "Wait until the page is fully loaded" sounds sufficient, but Claude's idea of "loaded" and the renderer's idea of "finished" are not the same event. Name the number of seconds.

The verification step mattered more than anything else. With no waits and no verification, 26 of 42 runs (about 62%) reached the end. Adding two things — a wait with an explicit duration, and "confirm the success condition visually after the action; stop and report if it isn't met" — moved completion to 40 of 42 runs (about 95%). Average runtime grew from 1m48s to 2m21s. Thirty-three seconds, against the several minutes a failed run costs in manual rework.

The two remaining failures were loud, not silent. After the verification step went in, a failing run always stops and says "I could not confirm the success message." It no longer returns a wrong answer quietly. That change mattered more to me than the percentage did.

The same site behaves differently by time of day. First paint on the console felt roughly twice as slow during weekday mornings. If you put a task on a schedule, set the wait generously by default.

On screens where the numbers move, always reconcile against the previous value. My notes from letting Claude adjust mediation priorities are in three weeks of letting Claude in Chrome tune my AdMob mediation priorities.

Verify the MCP Server Before the Task Starts

Miss a "Disconnected" badge, run the task anyway, collect an empty result ten minutes later. After doing that more than once, I collapsed the checks into a single script. It settles three things before anything else runs: port conflicts, missing environment variables, and reachability.

// preflight.mjs — verify MCP servers before running a Claude in Chrome task
// Run with: node preflight.mjs
import net from 'node:net';
 
const CHECKS = [
  { name: 'my-mcp-server', host: '127.0.0.1', port: 3333, env: ['MCP_API_KEY'] },
  { name: 'sheets-mcp', host: '127.0.0.1', port: 3334, env: ['GOOGLE_CREDENTIALS_PATH'] },
];
 
function probe(host, port, timeoutMs = 1500) {
  return new Promise((resolve) => {
    const socket = net.connect({ host, port });
    const done = (reachable) => {
      socket.destroy();
      resolve(reachable);
    };
    socket.setTimeout(timeoutMs);
    socket.once('connect', () => done(true));
    socket.once('timeout', () => done(false));
    socket.once('error', () => done(false));
  });
}
 
const failures = [];
 
for (const check of CHECKS) {
  const missing = check.env.filter((key) => !process.env[key]);
  const reachable = await probe(check.host, check.port);
 
  if (missing.length > 0) {
    failures.push(`${check.name}: missing environment variables (${missing.join(', ')})`);
  }
  if (!reachable) {
    failures.push(`${check.name}: cannot reach ${check.host}:${check.port}`);
  }
  if (missing.length === 0 && reachable) {
    console.log(`OK  ${check.name} (${check.host}:${check.port})`);
  }
}
 
if (failures.length > 0) {
  console.error('\nPreflight failed:');
  for (const line of failures) console.error(`  - ${line}`);
  process.exit(1);
}
 
console.log('\nAll checks passed. Safe to start the task.');

The important line is process.exit(1). A script that only prints a warning is a script whose warnings you eventually stop reading. Make it fail loudly and you can't proceed by accident.

When reachability fails, find out who owns the port.

# macOS / Linux — identify the process listening on port 3333
lsof -nP -iTCP:3333 -sTCP:LISTEN
 
# Terminate it only if it is a leftover from a previous run
kill "$(lsof -t -nP -iTCP:3333 -sTCP:LISTEN)"

In my case the answer was nearly always a previous MCP server process that never fully exited. That is usually what "restart the Cowork app and it works again" is actually fixing. For a worked example of chasing a backend error from the browser side, see how we fixed Stripe webhook HTTP 500 errors using Claude in Chrome.

Which Fix to Try First

To spend less time guessing, here is the order I work down for each symptom. In my setup, isolation usually finishes within two attempts.

When a fix doesn't land, go back to the leftmost column. Starting to fix a symptom you can't state in one sentence is how an afternoon disappears.

Claude in Chrome is an automation tool, but what actually made it dependable wasn't the automation. It was arranging things so a failure tells me where it stopped. A named wait duration and a verification step. Those two additions turned my weekly report pull from something I watched into something I only touch when it complains.

If you do one thing after reading this, pick the task that fails most often and append a single sentence after its final action: "confirm the success condition visually, and stop and report if it isn't met." Highest return, one line of typing.

If you'd like to start from the basics instead, the Claude in Chrome and Cowork beginner's guide is a solid starting point.