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.

Stop Guessing at Wait Durations

Stretching three seconds to six fixed one screen at one time of day. If first paint really is twice as slow during the morning rush, six seconds will eventually be too short — and on a quiet afternoon it throws away four seconds on every run.

What held up better was to stop guessing the number and describe the condition instead.

Check every 2 seconds, for up to 30 seconds, until the heading "This week's
earnings" is visible and the table below it has at least one row of data.
If it has not appeared after 30 seconds, take a screenshot, stop, and tell me
how far the page had rendered.

Three things are doing work in that phrasing.

• The thing being waited on is a concrete object on screen — a heading string and a table row — not the abstract idea of "loaded"
• The polling interval and the ceiling are both given as numbers
• What happens at the ceiling is spelled out

Drop the third one and Claude decides for itself when to give up and move on. "Wait until it appears" leaves the stopping rule entirely on the reader's side of the conversation.

The practical difference from a fixed wait: fast days proceed immediately, slow days keep waiting. My weekly report prompt got visibly longer, but I stopped adjusting the number by time of day.

Applying this to every action is a mistake, though. The prompt balloons, and a sprawling prompt becomes its own failure mode. I keep a fixed duration as the default for scheduled runs and convert only the one or two genuinely slow screens — the AdMob console being the obvious one — to the polling form.

What the Visual Path Costs You Instead

Switching to screenshots at step four of the isolation procedure works. It is not free, though, and leaving "show me the screen if you get stuck" permanently in a production prompt comes back as a different symptom.

Images are billed by area. The estimate given in the documentation is width in pixels × height in pixels ÷ 750, with anything longer than 1568px on its long edge scaled down into that bound before the conversion. Running common viewports through the formula:

These come from the formula, not from a bill, so treat them as order-of-magnitude figures. Two things fall out of the table. Capturing at a higher resolution barely matters, because the downscale pulls everything back toward roughly 2,000 tokens. And that figure is still an order of magnitude above reading a heading and a table as text, which lands in the hundreds to low thousands.

Ask for a screenshot after each of ten steps and the images alone add up to around 20,000 tokens. Priced at $3 per million input tokens that is about six cents a run — not a number worth thinking about for a weekly task.

Context is where it actually bites, well before billing does. Some of the mid-task stops described earlier turned out to be self-inflicted: I had switched to the visual path to diagnose something and never switched back, then filled the window with my own screenshots. Show the screen while you are hunting for the cause; return to the text path once you have found it. I treat the visual path as a diagnostic instrument rather than something that lives in the production prompt. The only screenshot I leave behind is the success check on the final step.

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.

Measure Completion Rate in Your Own Setup

The 62% and the 95% belong to two screens I happen to open every week: the AdMob console and the App Store Connect sales view. A different target has a different starting point and a different ceiling. Borrow the shape of the result by all means, but adopting the numbers as your own is how you end up fixing the wrong thing.

So I append one line per run and let the arithmetic happen later. Nothing elaborate — an append and a summary.

// runlog.mjs — append one line per run, then report completion rate and median duration
// Record:  node runlog.mjs log admob-weekly ok 141
//          node runlog.mjs log admob-weekly fail 63 "success message never confirmed"
// Report:  node runlog.mjs report admob-weekly
import { appendFileSync, readFileSync, existsSync } from 'node:fs';
 
const FILE = 'run-log.tsv';
const [, , cmd, task, ...rest] = process.argv;
 
if (cmd === 'log' && task) {
  const [result, seconds, note = ''] = rest;
  appendFileSync(FILE, [new Date().toISOString(), task, result, seconds, note].join('\t') + '\n');
  console.log(`recorded: ${task} ${result} ${seconds}s`);
  process.exit(0);
}
 
if (cmd !== 'report' || !task || !existsSync(FILE)) {
  console.error('usage: node runlog.mjs log <task> <ok|fail> <seconds> [note]');
  console.error('       node runlog.mjs report <task>');
  process.exit(1);
}
 
const rows = readFileSync(FILE, 'utf8').trim().split('\n')
  .map((line) => line.split('\t'))
  .filter((cols) => cols[1] === task);
 
if (rows.length === 0) {
  console.error(`no runs recorded for ${task}`);
  process.exit(1);
}
 
const ok = rows.filter((cols) => cols[2] === 'ok');
const median = (values) => {
  const sorted = [...values].sort((a, b) => a - b);
  return sorted.length ? sorted[Math.floor(sorted.length / 2)] : 0;
};
 
console.log(`${task}: ${ok.length} of ${rows.length} completed (${Math.round((ok.length / rows.length) * 100)}%)`);
console.log(`median duration of completed runs: ${median(ok.map((cols) => Number(cols[3])))}s`);
 
for (const cols of rows.filter((c) => c[2] === 'fail')) {
  console.log(`  failed ${cols[0].slice(0, 10)} — ${cols[4] || '(no note)'}`);
}

Median rather than mean, because one run that fought on until the very end will drag an average somewhere unhelpful. The median stays close to what a normal run actually feels like.

The part that repays the effort is refusing to leave the failure note blank. I watch how many distinct notes accumulate more closely than I watch the percentage. A column of "success message never confirmed" points at the prompt. Notes that keep scattering into new shapes usually mean the problem is the choice of target, not the wording — that is my working rule, at least.

Ten runs is enough for the shape to show. Folding the record step into the same routine as the preflight check from the previous section is what made me keep doing it.

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.