Bug Inbox

The bug inbox is your central view of every issue ClickProbe has found across all your projects. Navigate to it at /app/bugs.

Bugs appear as soon as an AI session reports them. You can triage them from the inbox without leaving the page — confirm, dismiss, retest, or export to GitHub/GitLab, all in one place.

Repeated defects are grouped, not just listed twice

Different exploration sessions have no memory of each other. If two sessions independently stumble onto the same defect, ClickProbe recognises the match by default — the inbox shows it as one row with an occurrence count (×N next to the title), not N separate rows.

• Each session that finds the same defect still gets its own recorded occurrence — nothing is ever silently dropped or merged away. Open the row’s drawer and expand Occurrences to see every sighting: when it happened, which session found it, and the exact page path.
• Resolving (or dismissing) a grouped row resolves every occurrence in the group — you don’t have to triage each sighting separately.
• Exporting a grouped row creates exactly one GitHub/GitLab issue, no matter how many times the underlying defect has been found. Later occurrences of the same defect link back to that same issue automatically instead of opening a second one.
• Add ?include_duplicates=true to the URL (or the API) to see every individual occurrence as its own row instead of the grouped view.

What grouping does not catch

Grouping works by recognising the same defect type, the same page, and enough shared wording between reports — it is deliberately conservative: when it isn’t confident two reports describe the same thing, it leaves them as separate rows rather than risk merging two genuinely different bugs into one (silently hiding a real, distinct defect is treated as the worse outcome). Two honest limits follow from that:

• Two genuinely different defects that happen to produce a very similar-sounding report on the same page can group together if the wording overlaps enough — this is rare, and you can always tell them apart from the individual descriptions in the expanded Occurrences list.
• The same defect can still show up as more than one row if the AI describes it differently across sessions, or if a create-form and an edit-form version of the same field-validation gap are genuinely different code paths. Grouping recovers a real share of repeats, not every one — it is not a promise that identical-looking rows never appear.

If you spot two rows you believe are the same defect that weren’t grouped automatically, use Dismiss → “duplicate” on the redundant one and note the row it duplicates — that stays a manual, one-time action, the same way it always has.

Keyboard Shortcuts

Filter Syntax

Filters are applied as URL query parameters, so every filtered view is a shareable link you can bookmark or paste into a ticket.

Parameters combine with AND logic. Example — all new critical bugs in a project since January:

/app/bugs?status=new&severity=critical&project_id=<uuid>&since=2026-01-01

Reading the Drawer

Click any row (or press Enter on the selected row) to open the detail drawer on the right.

The drawer contains:

Two bugs of the same fingerprint are grouped (see below) — only the first-seen occurrence’s own Console errors / Network / Expected-Actual are shown, even if a later occurrence of the same defect happened to capture richer evidence. This is a known, accepted limitation, not a bug in the drawer itself.

Bug Actions

Confirm

Marks the bug as a genuine issue.

• Keyboard: c with the row selected
• Button: Confirm in the drawer or the row action menu
• Transition: new → confirmed

Dismiss

Marks the bug as not worth acting on (false positive, known issue, won’t fix).

• Button: Dismiss in the drawer (a reason is required)
• Transition: new → dismissed, confirmed → dismissed, exported → dismissed

The dismiss reason is stored and visible in the drawer. It is included in webhook payloads.

Retest

Enqueues a new re-verification session restricted to this one bug — it runs in a dedicated mode that skips ordinary exploration and goes straight to checking whether this specific bug still reproduces, recording one of four outcomes to a separate verification status (shown as a badge in the drawer, independent of the workflow status below): verified fixed, still present, cannot reproduce, or — if the session could not reliably reach the target at all — no verdict, with the reason shown instead.

• Button: Retest in the drawer
• Transition: new → retesting, confirmed → retesting

🔴 Corrected: this section previously claimed the bug’s workflow status “automatically transitions back to new (still broken) or confirmed (bug confirmed by retest)” and that a notification email would follow — neither is accurate. What actually happens: once the retest session ends, a background sweep reverts the workflow status to whatever it was before the retest started (new or confirmed), regardless of what the verdict was — the workflow status and the verification verdict are two independent things, and only the verification badge reflects the retest’s actual outcome. No email is sent for a retest completing; email notifications currently cover session-complete and critical-bug alerts only, not a rerun verdict specifically.

If a verdict (cannot reproduce or verified fixed) turns out to be wrong — the session couldn’t actually reach the app, or you have new information — use Reopen verification in the drawer (shown only when the verification badge is in one of those two states) to reset it back to unverified so a future retest can check it again.

Export

Creates a GitHub Issue or GitLab Issue from this bug and links it in the drawer.

• Button: Export in the drawer
• Requires: A tracker must be configured for the project (Project settings → Tracker).
• Transition: new → exported, confirmed → exported

The created issue includes reproduction steps, severity, and a link back to this drawer, where screenshots are viewable (we don’t embed screenshots directly in third-party issues, to avoid sending a capture of your application to another service). See docs/user/tracker-integration.md for tracker setup.

Resolve

Marks a bug as fixed, won’t-fix, or a duplicate — the terminal “done” status, tracked separately from dismissed so MTTR and fixed-bug reporting only count real fixes.

• Button: Resolve in the drawer
• Requires: the bug must already be confirmed, retesting, or exported — a new bug cannot resolve directly (confirm it first)
• Transition: confirmed → resolved, retesting → resolved, exported → resolved
• Can also be done by a coding agent via the clickprobe.resolve_bug MCP tool — see Resolve bugs from your IDE

Reopen

Moves a dismissed or resolved bug back to new so it can be triaged again.

• Button: Reopen in the drawer (only visible on dismissed and resolved bugs)
• Transition: dismissed → new, resolved → new

Bulk Actions

Select multiple bugs using x (or click the checkbox on each row), then use the toolbar that appears at the top of the table:

Maximum 100 bugs per bulk operation. The toolbar shows the count of selected bugs.

Saved Views

The navigation bar above the table includes preset views:

A My bugs view (filtering to bugs assigned to you) is visible but disabled in this beta — the assignee filter param itself works (?assignee=<user_id>), but nothing yet resolves the special value me to your own user ID.

You can bookmark any custom filter URL to create your own saved views.

Terminology

ClickProbe always uses the word “bug” internally. GitHub and GitLab call their records “issues” — the exported items in those systems follow that naming, but the ClickProbe UI always calls them bugs.