[GH-ISSUE #8141] [Bug] CLI observe-web-session emits no armed progress, so a caller cannot tell when to perform the action #4686

New issue

Open

opened 2026-10-31 00:52:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:52:26 +00:00

Owner

Originally created by @Rinkia on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8141

Before submitting

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

Area

Browser and web observation

Observed behavior

observe_web_session arms a window for an external user action. The two surfaces signal arming differently:

MCP sends the progress notification "Browser observation armed; perform the requested user action now". In my run it arrived about 1.5 s after the call started, followed by "Browser observation window ended".
CLI (rea observe-web-session) writes nothing to stderr, so a caller has no armed signal.

By contrast, rea observe-web-execution prints {"rea_progress": … "Browser execution observation armed; perform the requested action now"} on stderr, and docs/web-runtime.md tells callers to wait for that event.

In my first CLI run, I waited for an armed line that never came, and the actions ran after the window had ended. The result was an empty timeline with only attach_limited. When I used a fixed 2 s delay instead, the timeline was complete and correct: reload, lifecycle, pushState, hash change, redirect to the committed page, and an out-of-policy navigation that ended the window without a URL.

Likely cause

src/cli/browserCommands.ts calls observeWebSession(provider, parsed.data, { signal }) without a progress reporter.
The MCP registration in src/server/registerBrowserTools.ts passes { signal, progress }.
src/cli/webRuntimeCommands.ts defines a stderr runtimeProgress reporter for observe-web-execution.

Expected behavior

The CLI should emit the same armed and ended progress lines as observe-web-execution on stderr, so scripts can act only after arming.

Reproduction

Container: Linux x64, Node 24.22.1, Chrome for Testing 145.0.7632.6 headless with --remote-debugging-port=9222. Seen on the 6.8.0 release and on main at 45cc93596.

Run rea observe-web-session http://127.0.0.1:9222 <target_id> --observation-ms 9000 --format json > out.json 2> progress.log.
When it finishes, progress.log is empty.
For comparison, rea observe-web-execution http://127.0.0.1:9222 <target_id> --observation-ms 5000 --format json 2> progress.log writes the armed line.
The MCP call observe_web_session with _meta.progressToken returns the armed and ended notifications.

Originally created by @Rinkia on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8141 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Browser and web observation ### Observed behavior `observe_web_session` arms a window for an external user action. The two surfaces signal arming differently: - **MCP** sends the progress notification "Browser observation armed; perform the requested user action now". In my run it arrived about 1.5 s after the call started, followed by "Browser observation window ended". - **CLI** (`rea observe-web-session`) writes nothing to stderr, so a caller has no armed signal. By contrast, `rea observe-web-execution` prints `{"rea_progress": … "Browser execution observation armed; perform the requested action now"}` on stderr, and `docs/web-runtime.md` tells callers to wait for that event. In my first CLI run, I waited for an armed line that never came, and the actions ran after the window had ended. The result was an empty timeline with only `attach_limited`. When I used a fixed 2 s delay instead, the timeline was complete and correct: reload, lifecycle, `pushState`, hash change, redirect to the committed page, and an out-of-policy navigation that ended the window without a URL. ### Likely cause - `src/cli/browserCommands.ts` calls `observeWebSession(provider, parsed.data, { signal })` without a `progress` reporter. - The MCP registration in `src/server/registerBrowserTools.ts` passes `{ signal, progress }`. - `src/cli/webRuntimeCommands.ts` defines a stderr `runtimeProgress` reporter for `observe-web-execution`. ### Expected behavior The CLI should emit the same armed and ended progress lines as `observe-web-execution` on stderr, so scripts can act only after arming. ### Reproduction Container: Linux x64, Node 24.22.1, Chrome for Testing 145.0.7632.6 headless with `--remote-debugging-port=9222`. Seen on the 6.8.0 release and on `main` at `45cc93596`. 1. Run `rea observe-web-session http://127.0.0.1:9222 <target_id> --observation-ms 9000 --format json > out.json 2> progress.log`. 2. When it finishes, `progress.log` is empty. 3. For comparison, `rea observe-web-execution http://127.0.0.1:9222 <target_id> --observation-ms 5000 --format json 2> progress.log` writes the armed line. 4. The MCP call `observe_web_session` with `_meta.progressToken` returns the armed and ended notifications.

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

No description provided.

Rows
Columns