[GH-ISSUE #7167] capture_browser_scenario fails with browser.mode="connect"; same scenario with mode="launch" works #4289

Open
opened 2026-10-31 00:48:33 +00:00 by bsakaguchi · 4 comments
Owner

Originally created by @juanfrilopez on GitHub (Oct 25, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7167

Summary

capture_browser_scenario (CLI and MCP) always fails with execution_failure when browser.mode is "connect", against a CDP endpoint that works fine with every other REA tool and with playwright-core directly. The same scenario shape with browser.mode: "launch" succeeds.

Environment

  • rea-agents 6.8.0 (npm global, rea CLI)
  • Node.js 26.12.1, npm 11.20.0
  • macOS (Apple Silicon, Homebrew)
  • Target browser: Chrome for Testing 156.0.8078.4 (Playwright chromium-1248) launched with --remote-debugging-port=9222 --user-data-dir=<profile>
  • rea doctor reports no problems besides missing native engines (Ghidra/Hopper/IDA), which are unrelated

Steps to reproduce

  1. Launch a Chrome-family browser with a loopback CDP endpoint, e.g. --remote-debugging-port=9222
  2. Confirm the endpoint works: rea list-browser-targets http://127.0.0.1:9222 lists the page target
  3. Run a minimal connect-mode scenario:
{
  "browser": { "mode": "connect", "cdp_endpoint": "http://127.0.0.1:9222", "target_id": "<target from list-browser-targets>" },
  "start_url": { "url": "https://example.com/", "query": [] },
  "actions": [
    { "step_id": "settle", "action": "wait_for_timeout", "duration_ms": 1000 }
  ],
  "capture": { "after_each_step": [], "at_end": ["url"], "events": [], "network": { "request_body": false, "response_body": false, "header_values": false } }
}
rea capture-browser-scenario scenario.json --format json

Expected

Scenario evidence, like the launch mode returns.

Actual

{"error":"Browser scenario capture failed","code":"execution_failure","category":"execution_failure","message":"Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed.","retryable":false,"remediation":{"action":"Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed."},"details":{"provider_id":"rea-playwright-browser-scenario","operation":"capture_browser_scenario"}}

rea doctor reports nothing actionable for this failure.

What works

  • The exact same scenario with "mode": "launch" and executable_path → returns evidence normally
  • rea list-browser-targets http://127.0.0.1:9222 → lists targets
  • rea capture-web-screenshot and rea analyze-web-bundle against the same endpoint/target → work
  • Connecting with REA's bundled playwright-core directly:
const { chromium } = require("rea-agents/node_modules/playwright-core");
const browser = await chromium.connectOverCDP("http://127.0.0.1:9222"); // works

Notes

  • Failure is deterministic (100% of connect-mode attempts, several targets/URLs), also via the MCP tool capture_browser_scenario
  • The endpoint is plain http://127.0.0.1:9222 (no auth); curl http://127.0.0.1:9222/json/version responds normally
  • Use case: analyzing a logged-in web app in a persistent browser profile; connect mode is the only scenario mode that can reuse that session, since launch uses an owned temporary profile

Thanks for REA — the JavaScript/Electron static analysis and CDP observation tools have been excellent.

Originally created by @juanfrilopez on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7167 ## Summary `capture_browser_scenario` (CLI and MCP) always fails with `execution_failure` when `browser.mode` is `"connect"`, against a CDP endpoint that works fine with every other REA tool and with `playwright-core` directly. The same scenario shape with `browser.mode: "launch"` succeeds. ## Environment - `rea-agents` 6.8.0 (npm global, `rea` CLI) - Node.js 26.12.1, npm 11.20.0 - macOS (Apple Silicon, Homebrew) - Target browser: Chrome for Testing 156.0.8078.4 (Playwright chromium-1248) launched with `--remote-debugging-port=9222 --user-data-dir=<profile>` - `rea doctor` reports no problems besides missing native engines (Ghidra/Hopper/IDA), which are unrelated ## Steps to reproduce 1. Launch a Chrome-family browser with a loopback CDP endpoint, e.g. `--remote-debugging-port=9222` 2. Confirm the endpoint works: `rea list-browser-targets http://127.0.0.1:9222` lists the page target 3. Run a minimal connect-mode scenario: ```json { "browser": { "mode": "connect", "cdp_endpoint": "http://127.0.0.1:9222", "target_id": "<target from list-browser-targets>" }, "start_url": { "url": "https://example.com/", "query": [] }, "actions": [ { "step_id": "settle", "action": "wait_for_timeout", "duration_ms": 1000 } ], "capture": { "after_each_step": [], "at_end": ["url"], "events": [], "network": { "request_body": false, "response_body": false, "header_values": false } } } ``` ``` rea capture-browser-scenario scenario.json --format json ``` ## Expected Scenario evidence, like the launch mode returns. ## Actual ```json {"error":"Browser scenario capture failed","code":"execution_failure","category":"execution_failure","message":"Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed.","retryable":false,"remediation":{"action":"Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed."},"details":{"provider_id":"rea-playwright-browser-scenario","operation":"capture_browser_scenario"}} ``` `rea doctor` reports nothing actionable for this failure. ## What works - The exact same scenario with `"mode": "launch"` and `executable_path` → returns evidence normally - `rea list-browser-targets http://127.0.0.1:9222` → lists targets - `rea capture-web-screenshot` and `rea analyze-web-bundle` against the same endpoint/target → work - Connecting with REA's bundled `playwright-core` directly: ```js const { chromium } = require("rea-agents/node_modules/playwright-core"); const browser = await chromium.connectOverCDP("http://127.0.0.1:9222"); // works ``` ## Notes - Failure is deterministic (100% of connect-mode attempts, several targets/URLs), also via the MCP tool `capture_browser_scenario` - The endpoint is plain `http://127.0.0.1:9222` (no auth); `curl http://127.0.0.1:9222/json/version` responds normally - Use case: analyzing a logged-in web app in a persistent browser profile; connect mode is the only scenario mode that can reuse that session, since launch uses an owned temporary profile Thanks for REA — the JavaScript/Electron static analysis and CDP observation tools have been excellent.
Author
Owner

@akushonkamen commented on GitHub (Oct 26, 2026):

I'd like to take this on. I can reproduce the connect/launch asymmetry locally (macOS arm64, Chrome for Testing with CDP on 9222) and will compare the connect branch against the launch branch in the browser scenario provider, land a regression test that runs the same scenario against both modes, and open a PR.

<!-- gh-comment-id:6405930428 --> @akushonkamen commented on GitHub (Oct 26, 2026): I'd like to take this on. I can reproduce the connect/launch asymmetry locally (macOS arm64, Chrome for Testing with CDP on 9222) and will compare the connect branch against the launch branch in the browser scenario provider, land a regression test that runs the same scenario against both modes, and open a PR.
Author
Owner

@XinwangTao commented on GitHub (Oct 26, 2026):

这个用例很有价值:connect 模式是复用持久化浏览器会话(登录态)的唯一路径,launch 模式用临时 profile 覆盖不了。@akushonkamen 的 PR #7188 方向对——Chromium 对 connectOverCDP 的 context 管理限制确实是常见差异点。两点建议:一是回归测试尽量覆盖不同 Chromium 版本(如较老的 Chrome for Testing 与新版),connect 模式下 context/incognito 行为版本间差异很大;二是错误信息里把"context 受限"与"endpoint 不可达/协议版本不匹配"区分开,避免用户拿到笼统的 execution_failure 后再跑 doctor 无果(本 issue 就踩到了)。

<!-- gh-comment-id:6411339593 --> @XinwangTao commented on GitHub (Oct 26, 2026): 这个用例很有价值:connect 模式是复用持久化浏览器会话(登录态)的唯一路径,launch 模式用临时 profile 覆盖不了。@akushonkamen 的 PR #7188 方向对——Chromium 对 connectOverCDP 的 context 管理限制确实是常见差异点。两点建议:一是回归测试尽量覆盖不同 Chromium 版本(如较老的 Chrome for Testing 与新版),connect 模式下 context/incognito 行为版本间差异很大;二是错误信息里把"context 受限"与"endpoint 不可达/协议版本不匹配"区分开,避免用户拿到笼统的 execution_failure 后再跑 doctor 无果(本 issue 就踩到了)。
Author
Owner

@morluto commented on GitHub (Oct 26, 2026):

Thank you for the connect-mode report. #7188 has now landed fixes for independently reproduced attachment failures, including a macOS zero-page endpoint case, and records real Linux and macOS browser validation. I am keeping this issue open because that PR explicitly did not reproduce the complete private-target failure in this report. A rerun of the original scenario on a current build would help determine what remains; no new browser run was performed in this triage.

<!-- gh-comment-id:6428640135 --> @morluto commented on GitHub (Oct 26, 2026): Thank you for the connect-mode report. #7188 has now landed fixes for independently reproduced attachment failures, including a macOS zero-page endpoint case, and records real Linux and macOS browser validation. I am keeping this issue open because that PR explicitly did not reproduce the complete private-target failure in this report. A rerun of the original scenario on a current build would help determine what remains; no new browser run was performed in this triage.
Author
Owner

@XinwangTao commented on GitHub (Oct 27, 2026):

既然 #7188 只复现了 attachment 失败而未覆盖本报告的完整 private-target 失败,建议在 issue 里固化一个可复现 checklist:报告者重跑时把 CDP 启动参数(--remote-debugging-port + --user-data-dir 的组合)、目标页面是否本身是 private/隔离 profile、场景里 attachment 的 target 类型(tab/window/iframe)三列写清楚,并附上当前构建下 rea doctor --connect 与 capture_browser_scenario 的原始输出。connect 模式的失败点经常在"DevTools target 可见性"与"context 归属"之间,仅靠文字描述很难区分,结构化输出才能让维护者直接定位剩余差异。

<!-- gh-comment-id:6431184894 --> @XinwangTao commented on GitHub (Oct 27, 2026): 既然 #7188 只复现了 attachment 失败而未覆盖本报告的完整 private-target 失败,建议在 issue 里固化一个可复现 checklist:报告者重跑时把 CDP 启动参数(--remote-debugging-port + --user-data-dir 的组合)、目标页面是否本身是 private/隔离 profile、场景里 attachment 的 target 类型(tab/window/iframe)三列写清楚,并附上当前构建下 rea doctor --connect 与 capture_browser_scenario 的原始输出。connect 模式的失败点经常在"DevTools target 可见性"与"context 归属"之间,仅靠文字描述很难区分,结构化输出才能让维护者直接定位剩余差异。
Sign in to join this conversation.
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#4289
No description provided.