These docs are in English. If you prefer German, write us at beta@clickprobe.ai.

What the tester does to your app

ClickProbe’s AI has no knowledge of how your app works. It looks at what’s on the page, guesses what a button or a link does, and clicks it to find out — exactly like a human tester who has never seen the app before. That is the product: an intelligent monkey tester that finds bugs a self-confident test suite (or a coding agent grading its own work) misses.

That also means it will click things you did not expect it to click. Read this before you point ClickProbe at anything you would not want changed.

What it will do

  • Click buttons it does not understand, including ones that create, edit, or delete data. A real recorded session clicked a “Delete All” button in one of its earliest runs — the button turned out to be broken (nothing happened), which is exactly the class of bug the product exists to find.
  • Submit forms with plausible test data, including on pages that create real records in your database (test accounts, test orders, test content).
  • Accept or dismiss confirmation dialogs (“Are you sure you want to delete this?”) when it decides to test the flow all the way through.
  • Navigate anywhere on the target host your project is configured to explore, following links and navigation it discovers — it does not stay on the page you started it on.

What it will not do

  • It will not follow a link to a different host than your project’s target/staging/production URL — if you set nav_scope_mode: enforce in your proxy’s config.yaml. The shipped default is warn: an out-of-scope navigation from a click, a typed URL, a form submit, or anywhere else is allowed and made visible — logged and shown in your local dashboard — never silently refused. enforce is best suited to a single-origin app with no third-party sign-in: it cannot stop a same-host link that server-side-redirects to a different host (the shape an OAuth/SSO “Sign in with X” button takes) — that escape is still made visible, but not blocked. See Testing Your App on localhost for the full host-scope behaviour.
  • It will not open non-http/https URLs (file://, data:, etc. are refused unconditionally, in every mode).
  • It will not act outside your declared Sensitive areas (below) once you have declared them.

Sensitive areas — fencing off what it must not touch

On a project’s edit page, Sensitive areas lets you declare URL patterns the tester must leave alone: an exact path (/settings/danger-zone), a single wildcard segment (/*/delete), or ** for any number of segments (/admin/**). By default, a declared pattern is enforced: the process that actually drives the browser refuses a matching navigation or a matching DELETE/POST/PUT/PATCH request before it reaches your app. This is checked in two places, together:

  1. Before navigating — a chrome.navigate (or chrome.take_screenshot with a URL) to a matching URL is refused outright.
  2. Before a mutating request leaves the browser — a button whose JavaScript fires a DELETE/ POST/PUT/PATCH to a matching URL, without ever navigating, is aborted before your server ever sees it. This is the more common case in practice — most destructive buttons don’t change the URL at all.

What this does not cover, so you can judge the residual risk honestly:

  • A GET request is never blocked at the request level, even if its URL matches a sensitive pattern (only navigation to that URL is blocked — a plain page load or a read-only GET your app’s own code happens to issue is allowed through, deliberately: blocking every GET would also block ordinary page loads and break exploration outright).
  • A mutation with no network request at all — a purely client-side change (e.g. writing to localStorage/IndexedDB, or a UI-only “delete” with no server round-trip) — cannot be caught by a URL pattern, because there is no URL to match.
  • Enforcement is a setting on your own proxy (guardrail_mode in config.yaml, defaulting to “enforce”), the one machine you installed the proxy on. If you have changed it to warn (record but allow) or off, sensitive areas are not blocked on that machine — the dashboard’s “blocked by default” wording describes the shipped default, not a promise about a setting only your own machine knows.

Our standing advice: point ClickProbe at a staging or throwaway environment whenever you can. Reserve Production for a rerun that specifically needs to re-verify an already-known, already -understood bug — never for open-ended exploration — and always declare Sensitive areas before you do.

Confirmation dialogs

When the tester expects an action to open a browser dialog (confirm(), alert(), prompt()), it arms how to answer it — accept or dismiss — immediately before that action, and the choice applies to exactly that one dialog. It does not silently change how every dialog on the page behaves for the rest of the session. If a dialog opens that nothing was armed for, it is dismissed automatically and noted in the session’s console log, so you (and the AI) can tell a dismissed dialog apart from a genuinely broken button.

Test credentials

If you give the tester a login (see Test Credentials), use a dedicated, low-privilege test account — never a production administrator login. Everything above applies to whatever that account can reach.