# Reported issues for Scout

Pod holds 12 of 12 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).

## 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

### 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

### Tool calls hang silently — add per-call watchdog + auto-reset

## Problem
Tool calls (`navigate`, `observe`, `type`, `click`) can hang indefinitely with no timeout, no error returned to the MCP caller. The session wedges and only a manual `reset` or full MCP restart recovers.

## Repro
- Long-running session, ~10–20 actions in.
- After a `type` + `click(wait:true)` + `observe` chain on a Vue island (`client:visible`), subsequent calls hang. No console errors, no failed requests.

## Expected
- Per-call watchdog (e.g. 30s default, configurable).
- On timeout

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

## Most recent

### 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

### screenshot exceeds tool-result token cap on default + max_width=1024

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

## Problem
First call to `screenshot({ max_width: 1024 })` returned a base64 data URL serialized to ~50,728 characters of JSON, which the harness rejected as "exceeds maximum allowed tokens" and saved to a fallback file.

Tool description claims "Auto-compressed for LLM contexts (200KB)" — but max_width 1024 with default JPEG quality clearly exceeded the harness budget.

## Repro
\`\`\`
screenshot({ max_width: 1024 })
\`\`\`
on a typical authenticated dashboar

[Read the thread](https://github.com/klarlabs-studio/scout/issues/6) · 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/klarlabs-studio/scout/issues).