> ## Documentation Index
> Fetch the complete documentation index at: https://docs-preview.webcompute.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Blockers and CAPTCHA

> Handle blocker and CAPTCHA states with status, evidence, approvals, and human review instead of overpromising access.

Some browser jobs hit login walls, consent prompts, JavaScript dialogs, bot checks, CAPTCHA, or site-specific blocking. Treat those states as product signals. A production workflow should preserve evidence, stop when appropriate, and ask for review before risky recovery actions.

## Signals to inspect

| Surface                       | What to inspect                                                                       |
| ----------------------------- | ------------------------------------------------------------------------------------- |
| SDK browser status            | `status.blocker`, `status.captcha`, `status.activePage`, and `status.nextAction`      |
| Browser-code execution result | `result.status`, `result.observation`, `result.logs`, and returned page metadata      |
| CLI                           | `web browser status`, `web browser captcha-status`, and `web browser captcha-resolve` |
| MCP                           | `manage_browsers` actions `status`, `captcha_status`, and `captcha_resolve`           |
| REST                          | Browser status and CAPTCHA resolve endpoints in the OpenAPI reference                 |

## SDK handling

```ts theme={null}
const browser = await web.browser.create({
  recording: true,
  policy: { allowedDomains: ["example.com"] },
});

try {
  const result = await browser.playwright.execute({
    code: `
      await page.goto("https://example.com");
      return { title: await page.title(), url: page.url() };
    `,
    capture: { status: true, observation: { kind: "aria", includeOn: "always" } },
  });

  if (result.status?.blocker?.state === "detected" || result.status?.captcha?.state === "detected") {
    await queueHumanReview({
      browserId: browser.id,
      activePage: result.status.activePage,
      blocker: result.status.blocker,
      captcha: result.status.captcha,
      observation: result.observation,
    });
    return;
  }
} finally {
  await browser.close();
}
```

`queueHumanReview` represents your application review flow.

## Agent handling

```ts theme={null}
const result = await agent.run({
  startUrl: "https://www.nhtsa.gov/recalls",
  goal: "Search recalls for a sample 2020 Toyota Camry query. Do not enter personal data.",
});

if (result.status === "blocked" || result.status === "needs_confirmation") {
  await queueHumanReview({
    browserId: result.browserId,
    status: result.status,
    summary: result.text,
    steps: result.steps,
    needsConfirmation: result.needsConfirmation,
  });
}
```

Do not turn a blocked run into an empty success. Store enough context for a reviewer to decide whether to stop, retry, adjust policy, or continue manually.

## Recovery rules

| Case                    | Recommended response                                                                              |
| ----------------------- | ------------------------------------------------------------------------------------------------- |
| Login required          | Use documented secrets and approvals. Do not put credentials in prompts.                          |
| Consent or modal prompt | Inspect the page, then accept or dismiss only when the action is in scope.                        |
| CAPTCHA detected        | Stop for human review or use the documented resolver only when the host has approved that action. |
| Repeated blocker        | Stop and report the blocker instead of widening scope automatically.                              |
| Policy denial           | Treat it as an intentional boundary until the application changes policy.                         |

<Warning>
  Use blocker and review language in prompts, docs, and product UI. Webcompute can surface blocker and CAPTCHA state and expose resolver paths where supported, but production workflows should respect site rules and user approvals.
</Warning>

Reference: [blockers and CAPTCHA](/observe-and-debug/blockers-and-captcha), [status, events, and logs](/observe-and-debug/status-events-and-logs), [policy and proxy](/production/policy-and-proxy), and [MCP tool reference](/reference/mcp-tool-reference).