[GH-ISSUE #7251] [Docs] Agent skill: passive SPA capture defaults to the page origin; route agents to allowed_origins and completeness.excluded #4312

New issue

Closed

opened 2026-10-31 00:48:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:48:49 +00:00

Owner

Originally created by @yeaurpoong-think on GitHub (Oct 26, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7251

Before submitting

I searched the existing issues for a related documentation report.
I removed credentials, tokens, private paths, and sensitive target data.

Documentation location

.agents/skills/reverse-engineer-anything/SKILL.md, the target routing list, the bullet "User-owned browser page already open: list_browser_targets" (around line 131 at current main).

Problem

docs/browser-observation.md documents that "an individual capture defaults to the selected page's current origin". The agent skill routes a user-owned page to list_browser_targets and the inspection tools but does not carry that consequence: for a SPA whose data API lives on another origin, a default-scope passive capture returns only the page origin's requests and reads like "this app has no data API".

How it showed up: an agent inspected a logged-in third-party SaaS dashboard (user-owned session, passive CDP observation) to map which APIs it calls. The first inspect_web_page run without allowed_origins returned only page-data JSON; 339 requests to the backend subdomain were excluded as disallowed_origin. The agent nearly reported "no data API"; only completeness.excluded showed the filter. A second run that included JSON body shapes exceeded the MCP response budget and needed export_evidence_bundle.

Affected: agents following the skill for SPA traffic mapping.

Expected content

Proposed clarification, one bullet next to the browser routing lines:

Passive traffic capture of a SPA: the default scope is the page's own origin, and data APIs usually live on another origin. Find the API origins first (absolute URLs in loaded bundles, or a short unscoped probe), pass them in allowed_origins, and read completeness.excluded before reporting that an API is absent. For long captures with body shapes, use export_evidence_bundle instead of expecting an inline result.

Supporting evidence

docs/browser-observation.md: "Without an origin filter, discovery lists all eligible pages; an individual capture defaults to the selected page's current origin."
Observed result fields: completeness.excluded reported 339 requests as disallowed_origin on the first run.
NOT_ENOUGH_INFO for the exact REA server version used in that session (2026-10-14); the local skill metadata was version: "42". Not re-run on current main.

Additional context

Filed by Claude Code (claude-opus-5-5) on behalf of the user, who asked for this finding to be reported upstream. Related but distinct: #5994 (wording of the screenshot origin-scope refusal).

Originally created by @yeaurpoong-think on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7251 ### Before submitting - [x] I searched the existing issues for a related documentation report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location `.agents/skills/reverse-engineer-anything/SKILL.md`, the target routing list, the bullet "User-owned browser page already open: `list_browser_targets`" (around line 131 at current `main`). ### Problem `docs/browser-observation.md` documents that "an individual capture defaults to the selected page's current origin". The agent skill routes a user-owned page to `list_browser_targets` and the inspection tools but does not carry that consequence: for a SPA whose data API lives on another origin, a default-scope passive capture returns only the page origin's requests and reads like "this app has no data API". How it showed up: an agent inspected a logged-in third-party SaaS dashboard (user-owned session, passive CDP observation) to map which APIs it calls. The first `inspect_web_page` run without `allowed_origins` returned only page-data JSON; 339 requests to the backend subdomain were excluded as `disallowed_origin`. The agent nearly reported "no data API"; only `completeness.excluded` showed the filter. A second run that included JSON body shapes exceeded the MCP response budget and needed `export_evidence_bundle`. Affected: agents following the skill for SPA traffic mapping. ### Expected content Proposed clarification, one bullet next to the browser routing lines: > Passive traffic capture of a SPA: the default scope is the page's own origin, and data APIs usually live on another origin. Find the API origins first (absolute URLs in loaded bundles, or a short unscoped probe), pass them in `allowed_origins`, and read `completeness.excluded` before reporting that an API is absent. For long captures with body shapes, use `export_evidence_bundle` instead of expecting an inline result. ### Supporting evidence - `docs/browser-observation.md`: "Without an origin filter, discovery lists all eligible pages; an individual capture defaults to the selected page's current origin." - Observed result fields: `completeness.excluded` reported 339 requests as `disallowed_origin` on the first run. - NOT_ENOUGH_INFO for the exact REA server version used in that session (2026-10-14); the local skill metadata was `version: "42"`. Not re-run on current `main`. ### Additional context Filed by Claude Code (claude-opus-5-5) on behalf of the user, who asked for this finding to be reported upstream. Related but distinct: #5994 (wording of the screenshot origin-scope refusal).

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

bsakaguchi closed this issue

2026-11-04 12:09:20 +00:00