# Reported issues for Scout

Pod holds 13 of 13 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Scout](/mcp/scout-felixgeelhaar).

## Most discussed

### Stability + UX bugs surfaced during E2E driving of a Vue/Astro app

Feedback after using scout MCP (`scout 1.6.1`) to drive a full E2E walkthrough of a Vue + Astro + Go app (brotwerk). Most-impactful fix at top.

## Stability bugs

1. **Stale CDP node IDs after framework re-render.** `click`, `type`, `fill_form_semantic` cache CDP node refs from prior `annotated_screenshot` / `observe`. When Vue/React reconciles, refs invalidate but tools still use them → cryptic `cdp: error -32000: Could not find node with given id`. Fix: re-resolve selector to live nodeId at a

[Read the thread](https://github.com/klarlabs-studio/scout/issues/14) · 2026-05-20 · closed · 1 comment

### Expose video recording (Playwright recordVideo) via MCP

## Problem

Scout exposes \`start_recording\` / \`stop_recording\` / \`save_playbook\` / \`replay_playbook\` — but those record an *action playbook* (JSON of clicks/types for replay), not a screen video.

For demo / docs / landing-page work, the value is the **video** (MP4 / WebM) that you can embed. Playwright already supports this natively via \`browser.newContext({ recordVideo: { dir, size } })\` — scout just doesn't expose it.

## Workaround

Call Playwright directly:

\`\`\`js
const ctx = a

[Read the thread](https://github.com/klarlabs-studio/scout/issues/4) · 2026-05-02 · closed · 1 comment

### CDP connection stability + React compatibility issues

## Summary

While using Scout extensively to automate and demo a React SPA dashboard ([go-teamhealthcheck](https://github.com/felixgeelhaar/go-teamhealthcheck)), I encountered several issues that made the experience unreliable. Filing them together since they came up in the same session.

## Environment

- Scout MCP server (via Claude Code)
- Target: React 19 SPA with react-router-dom v7, served from Go backend on localhost
- Both headless and visible modes tested

## Issues

### 1. Frequent CDP

[Read the thread](https://github.com/klarlabs-studio/scout/issues/1) · 2026-03-26 · closed · 1 comment

### screenshot: add save_to_disk / output_path so captures return a file path instead of base64

## Problem

`screenshot` and `annotated_screenshot` return a base64 data URL inline. For an agent driving scout on behalf of a user, that image lands in the **agent's** context — it renders for the model but never reaches the human. There is no way to hand the capture over.

Encountered while running a scripted end-to-end walkthrough with screenshot milestones: every capture came back as base64, and the user simply saw nothing.

## Current workarounds, both bad

1. **Force an overflow.** Request

[Read the thread](https://github.com/klarlabs-studio/scout/issues/79) · 2026-08-01 · closed · 0 comments

### No viewport / device emulation: width params don't set the CSS viewport (responsive testing impossible)

## Summary

There is no way to set the browser **viewport size / emulate a device** through the MCP tools. Width parameters that *look* like they should control it (`screenshot.max_width`, `start_screen_recording.width/height`) only affect the **output image / capture frame**, not the page's CSS viewport. As a result, width-based `@media` breakpoints can't be exercised, so mobile/responsive layouts can't be verified.

## Repro

1. `configure { headless: true, fresh: true }` (also reproduces with

[Read the thread](https://github.com/klarlabs-studio/scout/issues/47) · 2026-06-28 · closed · 0 comments

### MCP: network capture returns zero requests after navigate() on a localhost SPA

## Summary

When debugging a same-origin SPA served on `127.0.0.1`, the network-capture tools report **zero** captured requests — not even the document or static JS assets — despite the page clearly loading and issuing periodic `fetch()` polls. This makes it impossible to answer the most common debugging question ("did this request fire, and what status did it return?").

## Environment

- Scout MCP server (69-tool), driving headless Chromium
- `configure` with `headless=true`, `allow_private_ip

[Read the thread](https://github.com/klarlabs-studio/scout/issues/42) · 2026-06-09 · closed · 0 comments

### Nice-to-haves: wait_for_navigation, dom_diff, extract_aria_violations

Three low-priority adds that would each save round-trips:

## 1. `wait_for_navigation`
`click(wait:true)` waits for full nav. SPA route changes (History API push) don't fire a real nav, so the option silently no-ops. Want a dedicated `wait_for_navigation({timeout, mode: "full" | "spa" | "any"})` that detects History API mutations + URL change + idle network.

## 2. `dom_diff`
Compare two `observe` snapshots and return only what changed:
```
{
  added: [...],
  removed: [...],
  changed_text: [{s

[Read the thread](https://github.com/klarlabs-studio/scout/issues/24) · 2026-05-22 · closed · 0 comments

### Add network_summary({since: "last_action"}) — collapse capture/check round-trip

## Problem
Today: `enable_network_capture(patterns)` → action → `failed_requests` → maybe `console_errors`. Three calls for one question ("did the click trigger a failed request?").

## Proposal
Single tool: `network_summary({since: "last_action" | "last_navigation" | "session_start"})`:
```
{
  total: 12,
  by_status: {"2xx": 10, "4xx": 1, "5xx": 1},
  failures: [
    {method: "POST", url: "/api/auth/signup", status: 500, body_snippet: "..."}
  ],
  pending: 0,
  duration_ms: 230
}
```

## Why

[Read the thread](https://github.com/klarlabs-studio/scout/issues/23) · 2026-05-22 · closed · 0 comments

## Most recent

### type should report committed value after framework microtask flush

## Problem
`type` returns the typed string immediately:
```
{selector: "input[type=email]", value: "x@y.z", action: "typed"}
```
But on frameworks with two-way binding (Vue v-model, Svelte bind:value), the value may be transformed, sanitized, or never committed. Caller has no way to know without a separate `observe`.

## Proposal
Mirror what `fill_form_semantic` already does:
```
{
  selector: "input[type=email]",
  typed: "x@y.z",
  committed: "x@y.z",            // re-read after rAF + microtas

[Read the thread](https://github.com/klarlabs-studio/scout/issues/22) · 2026-05-22 · closed · 0 comments

### annotated_screenshot: add stable node_handle alongside per-call label

## Problem
`annotated_screenshot` warns that labels are per-call only — re-shuffled on any DOM mutation. Multi-step flows (annotate → click → annotate again) can't reliably reference the same node, forcing the caller to recompute selectors.

## Proposal
Return a stable `node_handle` per element alongside the per-call label number:
```
{label: 7, node_handle: "h_a3f2", selector: "button.mode-tab", text: "Mit Passwort", ...}
```
- `node_handle` valid for as long as the node is alive (weak ref).
- 

[Read the thread](https://github.com/klarlabs-studio/scout/issues/19) · 2026-05-22 · closed · 0 comments

### Form submission silently fails: click_label on type=submit and dispatch_event(submit) don't fire @submit handlers

## Summary

Scout cannot drive form submission on a Vue 3 island that uses `@submit.prevent`. The handler never fires; no network request is dispatched; no console error surfaces. Two approaches both silently no-op:

1. `click_label` on the `<button type=\"submit\">` inside the form
2. `dispatch_event` with `event_type: \"submit\"` on the `<form>` element

The result is that Scout can fill a form (Vue v-model reactivity confirmed via `framework_reactive: true`), but cannot complete the canonical

[Read the thread](https://github.com/klarlabs-studio/scout/issues/13) · 2026-05-17 · closed · 0 comments

### wait_for / click failures lack diagnostic context

**Scout version**: 1.5.0 (30010ef)

## Problem
`wait_for` and `click` on a missing or stale selector return MCP error -32603 with the selector echoed back, but no information about what *was* present. Forces a manual fallback to `observe` to figure out why the selector didn't resolve.

## Repro
\`\`\`
click({ selector: "#tabgroup-access" })
\`\`\`
when the actual tabs render under `#tabgroup-sharing` (parent group):
\`\`\`
MCP error -32603: browse: timeout waiting for wait for selector on "#tabg

[Read the thread](https://github.com/klarlabs-studio/scout/issues/8) · 2026-05-10 · closed · 0 comments

### Allow loopback / private-IP navigation for local-dev workflows

## Problem

Scout currently blocks navigation to loopback addresses with:

\`\`\`
browse: blocked navigation to private/loopback IP 127.0.0.1
\`\`\`

This is sensible default for the public-web automation case, but it makes scout unusable for the *very common* dev workflow of "drive the local app I just built": vite/webpack/next dev server on localhost, locally-running daemon on a custom port, etc.

## Repro

\`\`\`
mcp.scout.navigate({url: \"http://127.0.0.1:4173/\"})
// → MCP error: failed to 

[Read the thread](https://github.com/klarlabs-studio/scout/issues/3) · 2026-05-02 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/felixgeelhaar/scout/issues).