morluto/rea

Fork 0

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

[GH-ISSUE #3452] [Bug] capture_electron_scenario does not block app.moveToApplicationsFolder; the target moved the operator's Electron runtime into /Applications #1294

New issue

Closed

opened 2026-10-16 21:03:52 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:03:52 +00:00

Owner

Originally created by @gkobayashi0 on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3452

Before submitting

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

Area

Process capture or runtime observation

Observed behavior

I ran capture-electron-scenario with a stock Electron 42.5.2 runtime (downloaded into a scratch directory) and an extracted third-party app directory. During startup the app called app.moveToApplicationsFolder(...). Electron moved the operator-supplied Electron.app from the scratch directory to /Applications/Electron.app and the app quit.

The capture failed with electronApplication.evaluate: Target page, context or browser has been closed. The partial timeline (29 events) contains ready, before-quit and will-quit, but no event for the move. The runtime stayed in /Applications after REA's cleanup (cleanup: terminated-owned-process).

Source check: scripts/electron-active-hook-boundaries.cjs blocks app.relaunch, app.setAsDefaultProtocolClient, app.setLoginItemSettings, shell.openExternal and shell.openPath. app.moveToApplicationsFolder is not in the list. (Source-derived; I did not test other methods.)

Reproduction

Observed once with the real app; I did not run a minimal fixture, to avoid moving the runtime again.

Download stock Electron 42.5.2 for darwin-arm64 into a non-Applications directory.
Use an app whose main process calls app.moveToApplicationsFolder() when not already in /Applications.
Run rea capture-electron-scenario scenario.json with executable_path set to that runtime, application_path set to the app directory, a separate --user-data-dir in args, and one wait action.
Observe the runtime bundle now at /Applications/Electron.app.

A minimal fixture would be a main script that calls app.moveToApplicationsFolder() inside app.whenReady(). NOT_ENOUGH_INFO on whether this reproduces without the conflict handler argument.

Expected behavior

docs/electron-observation.md says the active hook "blocks and records external shell/navigation, permission, download, popup, updater, and OS-integration effects". Moving the application bundle is an OS-integration effect, so I expected the call to be blocked and recorded as a timeline event (as relaunch is). Other filesystem-level app/shell methods may deserve the same review (for example shell.trashItem, app.setPath), but I have not tested them.

Impact and scope

The capture changed host state outside the scratch directory, and the evidence did not record it. An operator reading the timeline would not know that /Applications changed. The docs do state that the owned process is not a sandbox, so this is a gap in the declared blocked-effect list rather than a sandbox escape. "Move to Applications" prompts are common in macOS Electron apps, so other targets are likely to hit this; frequency is otherwise unknown.

REA version

Source ca7450b (local build of main)

Runtime and platform

Node 24.21.0; macOS 26 (Darwin 25.6.0) arm64; stock Electron 42.5.2

Originally created by @gkobayashi0 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3452 ### 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 Process capture or runtime observation ### Observed behavior I ran `capture-electron-scenario` with a stock Electron 42.5.2 runtime (downloaded into a scratch directory) and an extracted third-party app directory. During startup the app called `app.moveToApplicationsFolder(...)`. Electron moved the operator-supplied `Electron.app` from the scratch directory to `/Applications/Electron.app` and the app quit. The capture failed with `electronApplication.evaluate: Target page, context or browser has been closed`. The partial timeline (29 events) contains `ready`, `before-quit` and `will-quit`, but no event for the move. The runtime stayed in `/Applications` after REA's cleanup (`cleanup: terminated-owned-process`). Source check: `scripts/electron-active-hook-boundaries.cjs` blocks `app.relaunch`, `app.setAsDefaultProtocolClient`, `app.setLoginItemSettings`, `shell.openExternal` and `shell.openPath`. `app.moveToApplicationsFolder` is not in the list. (Source-derived; I did not test other methods.) ### Reproduction Observed once with the real app; I did not run a minimal fixture, to avoid moving the runtime again. 1. Download stock Electron 42.5.2 for darwin-arm64 into a non-Applications directory. 2. Use an app whose main process calls `app.moveToApplicationsFolder()` when not already in /Applications. 3. Run `rea capture-electron-scenario scenario.json` with `executable_path` set to that runtime, `application_path` set to the app directory, a separate `--user-data-dir` in `args`, and one `wait` action. 4. Observe the runtime bundle now at `/Applications/Electron.app`. A minimal fixture would be a main script that calls `app.moveToApplicationsFolder()` inside `app.whenReady()`. NOT_ENOUGH_INFO on whether this reproduces without the conflict handler argument. ### Expected behavior `docs/electron-observation.md` says the active hook "blocks and records external shell/navigation, permission, download, popup, updater, and OS-integration effects". Moving the application bundle is an OS-integration effect, so I expected the call to be blocked and recorded as a timeline event (as `relaunch` is). Other filesystem-level app/shell methods may deserve the same review (for example `shell.trashItem`, `app.setPath`), but I have not tested them. ### Impact and scope The capture changed host state outside the scratch directory, and the evidence did not record it. An operator reading the timeline would not know that `/Applications` changed. The docs do state that the owned process is not a sandbox, so this is a gap in the declared blocked-effect list rather than a sandbox escape. "Move to Applications" prompts are common in macOS Electron apps, so other targets are likely to hit this; frequency is otherwise unknown. ### REA version Source `ca7450b` (local build of main) ### Runtime and platform Node 24.21.0; macOS 26 (Darwin 25.6.0) arm64; stock Electron 42.5.2

bsakaguchi referenced this issue

2026-10-17 21:10:04 +00:00

[PR #1294] [MERGED] test(process): check malformed capture choices concurrently #2774

bsakaguchi closed this issue

2026-10-31 00:30:28 +00:00

bsakaguchi commented

2026-10-31 00:30:29 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 19, 2026):

matbrgz groups this issue with #3474 and #4393 in #4330, as Electron active hook gaps.

Merged PR #4562 says it fixes #4393. It changed the Electron hook boundaries script. Open PRs for this group: #3466 and #3471 (both for this issue) and #3559 (for #3474). PRs #3466, #3471 and #3559 may need a check against the #4562 change.

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 19, 2026): matbrgz groups this issue with #3474 and #4393 in #4330, as Electron active hook gaps. Merged PR #4562 says it fixes #4393. It changed the Electron hook boundaries script. Open PRs for this group: #3466 and #3471 (both for this issue) and #3559 (for #3474). PRs #3466, #3471 and #3559 may need a check against the #4562 change. 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

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

No description provided.

Rows
Columns