morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8312] [Bug] Windows Chrome CDP: `inspect-web-page` times out at `Page.enable` after successful target discovery #6539

New issue

Open

opened 2026-11-01 21:12:03 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:03 +00:00

Owner

Originally created by @KakraGeek on GitHub (Oct 31, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8312

Environment

REA: rea-agents@6.8.0, direct CLI, locally verified
OS: Windows; exact build not retained
Browser: Chrome-family browser with a dedicated temporary profile; exact version not retained
Node.js: exact version during the failing calls not retained
PowerShell: version during the failing calls not retained; 7.6.9 was verified during a separate, later diagnostic
Target: fictional local HTTP fixture and loopback CDP endpoint
MCP: not involved in the reported failing calls

Actual behavior

In a synthetic browser-observation investigation:

list-browser-targets succeeded against the local CDP endpoint, returning a page target matching the requested origin.
A subsequent inspect-web-page attempt with --observation-ms 1000 failed with a timeout reported at Page.enable.
A separate attempt with a 60-second command timeout failed at the same phase.
A separate observe-web-session attempt with --observation-ms 10000 failed with a timeout reported at Page.getFrameTree.

These findings are based on retained local execution summaries. The original failed-call stdout, stderr and raw CDP messages are unavailable.

Important limitation: The complete failed invocation transcript was not retained. Consequently, it cannot be independently confirmed that the failed inspection used precisely the same endpoint and target ID as the successful discovery. This is a potential confounding factor, not an established REA defect.

Known successful discovery invocation

The following arguments were recorded for the successful discovery call using the locally verified REA 6.8.0 CLI:

list-browser-targets http://127.0.0.1:9226 --allowed-origins http://127.0.0.1:50738 --format json

The command returned one matching synthetic page target.

Suggested reproduction procedure

Using a fresh, locally owned synthetic HTTP fixture and a dedicated Chrome-family profile with loopback CDP enabled:

rea list-browser-targets http://127.0.0.1:<CDP_PORT> --allowed-origins http://127.0.0.1:<FIXTURE_PORT> --format json

rea inspect-web-page http://127.0.0.1:<CDP_PORT> <TARGET_ID_FROM_DISCOVERY> --allowed-origins http://127.0.0.1:<FIXTURE_PORT> --observation-ms 1000 --format json

Use the same verified CDP endpoint and discovered target ID for both operations. The --format json option reflects the locally tested CLI version; current repository examples may differ.

This is a proposed reproduction procedure. It has not been independently completed end-to-end with a retained failure transcript.

Expected behavior

The inspection operation should return bounded page-inspection evidence or a specific protocol, connection or timeout error that identifies the failing phase.

Observed impact

Passive page inspection and session observation could not be accepted in this Windows synthetic environment.

No production impact or security vulnerability has been demonstrated.

Unknowns and possible confounding factors

Exact failed CDP endpoint and target-ID pairing
Raw Page.enable and Page.getFrameTree error details
Chrome version and Windows build
Whether target attachment state differed between discovery and inspection
Whether a newer REA release changes the behavior

No root cause is claimed.

Requested maintainer guidance

Are there known Windows/Chrome compatibility limitations for REA 6.8.0 passive CDP observation?
Could these reported timeout phases indicate a CDP session-attachment or endpoint-selection issue?
Which minimal non-sensitive diagnostic fields would best distinguish a REA protocol failure from an endpoint/target mismatch?
Is there a known fix or preferred newer release for retesting?

The report contains no authenticated application data, credentials, cookies or sensitive browser captures.

Originally created by @KakraGeek on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8312 ## Environment - REA: `rea-agents@6.8.0`, direct CLI, locally verified - OS: Windows; exact build not retained - Browser: Chrome-family browser with a dedicated temporary profile; exact version not retained - Node.js: exact version during the failing calls not retained - PowerShell: version during the failing calls not retained; 7.6.9 was verified during a separate, later diagnostic - Target: fictional local HTTP fixture and loopback CDP endpoint - MCP: not involved in the reported failing calls ## Actual behavior In a synthetic browser-observation investigation: 1. `list-browser-targets` succeeded against the local CDP endpoint, returning a page target matching the requested origin. 2. A subsequent `inspect-web-page` attempt with `--observation-ms 1000` failed with a timeout reported at `Page.enable`. 3. A separate attempt with a 60-second command timeout failed at the same phase. 4. A separate `observe-web-session` attempt with `--observation-ms 10000` failed with a timeout reported at `Page.getFrameTree`. These findings are based on retained local execution summaries. The original failed-call stdout, stderr and raw CDP messages are unavailable. **Important limitation:** The complete failed invocation transcript was not retained. Consequently, it cannot be independently confirmed that the failed inspection used precisely the same endpoint and target ID as the successful discovery. This is a potential confounding factor, not an established REA defect. ## Known successful discovery invocation The following arguments were recorded for the successful discovery call using the locally verified REA 6.8.0 CLI: ```text list-browser-targets http://127.0.0.1:9226 --allowed-origins http://127.0.0.1:50738 --format json ``` The command returned one matching synthetic page target. ## Suggested reproduction procedure Using a fresh, locally owned synthetic HTTP fixture and a dedicated Chrome-family profile with loopback CDP enabled: ```text rea list-browser-targets http://127.0.0.1:<CDP_PORT> --allowed-origins http://127.0.0.1:<FIXTURE_PORT> --format json rea inspect-web-page http://127.0.0.1:<CDP_PORT> <TARGET_ID_FROM_DISCOVERY> --allowed-origins http://127.0.0.1:<FIXTURE_PORT> --observation-ms 1000 --format json ``` Use the **same verified CDP endpoint and discovered target ID** for both operations. The `--format json` option reflects the locally tested CLI version; current repository examples may differ. This is a proposed reproduction procedure. It has not been independently completed end-to-end with a retained failure transcript. ## Expected behavior The inspection operation should return bounded page-inspection evidence or a specific protocol, connection or timeout error that identifies the failing phase. ## Observed impact Passive page inspection and session observation could not be accepted in this Windows synthetic environment. No production impact or security vulnerability has been demonstrated. ## Unknowns and possible confounding factors - Exact failed CDP endpoint and target-ID pairing - Raw `Page.enable` and `Page.getFrameTree` error details - Chrome version and Windows build - Whether target attachment state differed between discovery and inspection - Whether a newer REA release changes the behavior No root cause is claimed. ## Requested maintainer guidance 1. Are there known Windows/Chrome compatibility limitations for REA 6.8.0 passive CDP observation? 2. Could these reported timeout phases indicate a CDP session-attachment or endpoint-selection issue? 3. Which minimal non-sensitive diagnostic fields would best distinguish a REA protocol failure from an endpoint/target mismatch? 4. Is there a known fix or preferred newer release for retesting? The report contains no authenticated application data, credentials, cookies or sensitive browser captures.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6539

No description provided.

Rows
Columns

[GH-ISSUE #8312] [Bug] Windows Chrome CDP: inspect-web-page times out at Page.enable after successful target discovery #6539