morluto/rea

Fork 0

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

[GH-ISSUE #479] [Bug] Reuse Hopper GUI windows across REA sessions for the same target #255

New issue

Open

opened 2026-10-15 18:23:02 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 18:23:02 +00:00

Owner

Originally created by @morluto on GitHub (Sep 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/479

Problem

On macOS, investigating one native app through multiple REA sessions can leave several Hopper windows open for the same work. The attached user screenshot shows four Hopper windows open alongside a single REA window. This makes it difficult to tell which window/session is active and creates unnecessary UI clutter during an agent investigation.

Observed behavior

During an investigation, multiple Hopper windows appeared while REA was being used. The visible windows show the same analysis database/document name. The behavior was reported as recurring when REA-backed Hopper analysis was used.

The screenshot does not expose the exact MCP/session IDs or prove which request launched each window, so the originating call sequence is unknown.

Relevant implementation detail

The current BinarySession path short-circuits open_binary when the same target and analysis profile are already active within one BinarySession, so repeated opens in that same session should reuse its active client.

However, each newly opened REA session creates a new Hopper client and HopperApplicationLauncher. The launcher starts Hopper's command-line helper for each bridge launch and documents that REA does not own the Hopper GUI process that LaunchServices may create or reuse. The code therefore does not provide an explicit cross-session reuse guarantee for the same target/document.

Steps to reproduce

On macOS, configure REA with Hopper as its native analysis provider.
Start multiple REA/MCP sessions (for example, separate agent sessions) against the same native binary or Hopper database.
Open the same target in each session and perform a Hopper-backed analysis operation.
Observe whether each session opens another Hopper window/document instead of focusing or reusing the existing target window.

Expected behavior

When multiple REA sessions analyze the same target, REA should reuse/focus the existing Hopper application/document where Hopper supports that behavior, or clearly document why a separate window is required. Reuse must not route analysis to the wrong target or mix session-specific bridge state.

Actual behavior

Multiple Hopper windows for the same apparent analysis document can be left open, with no visible indication tying each window to an REA session.

Investigation requested

Confirm whether separate MCP processes/sessions are each launching a new Hopper document/window.
Determine whether the supported Hopper CLI or LaunchServices can safely focus/reuse an existing document for the same target.
If cross-session reuse is not safe, prevent accidental duplicate opens where possible and expose which REA session owns each Hopper window/document.
Add a macOS regression check for repeated and concurrent opens of the same target.

Environment

OS: macOS (screenshot shows macOS)
Analysis provider: Hopper via REA
REA version: unknown
Hopper version: unknown
Target: Coffee Inc 2 app; exact binary/database path unknown
MCP client/session topology: unknown

Originally created by @morluto on GitHub (Sep 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/479 ## Problem On macOS, investigating one native app through multiple REA sessions can leave several Hopper windows open for the same work. The attached user screenshot shows four Hopper windows open alongside a single REA window. This makes it difficult to tell which window/session is active and creates unnecessary UI clutter during an agent investigation. ## Observed behavior During an investigation, multiple Hopper windows appeared while REA was being used. The visible windows show the same analysis database/document name. The behavior was reported as recurring when REA-backed Hopper analysis was used. The screenshot does not expose the exact MCP/session IDs or prove which request launched each window, so the originating call sequence is unknown. ## Relevant implementation detail The current `BinarySession` path short-circuits `open_binary` when the same target and analysis profile are already active within one `BinarySession`, so repeated opens in that same session should reuse its active client. However, each newly opened REA session creates a new Hopper client and `HopperApplicationLauncher`. The launcher starts Hopper's command-line helper for each bridge launch and documents that REA does not own the Hopper GUI process that LaunchServices may create or reuse. The code therefore does not provide an explicit cross-session reuse guarantee for the same target/document. ## Steps to reproduce 1. On macOS, configure REA with Hopper as its native analysis provider. 2. Start multiple REA/MCP sessions (for example, separate agent sessions) against the same native binary or Hopper database. 3. Open the same target in each session and perform a Hopper-backed analysis operation. 4. Observe whether each session opens another Hopper window/document instead of focusing or reusing the existing target window. ## Expected behavior When multiple REA sessions analyze the same target, REA should reuse/focus the existing Hopper application/document where Hopper supports that behavior, or clearly document why a separate window is required. Reuse must not route analysis to the wrong target or mix session-specific bridge state. ## Actual behavior Multiple Hopper windows for the same apparent analysis document can be left open, with no visible indication tying each window to an REA session. ## Investigation requested - Confirm whether separate MCP processes/sessions are each launching a new Hopper document/window. - Determine whether the supported Hopper CLI or LaunchServices can safely focus/reuse an existing document for the same target. - If cross-session reuse is not safe, prevent accidental duplicate opens where possible and expose which REA session owns each Hopper window/document. - Add a macOS regression check for repeated and concurrent opens of the same target. ## Environment - OS: macOS (screenshot shows macOS) - Analysis provider: Hopper via REA - REA version: unknown - Hopper version: unknown - Target: Coffee Inc 2 app; exact binary/database path unknown - MCP client/session topology: unknown

bsakaguchi added the

area: providers

bug

P2: medium

labels

2026-10-15 18:23:02 +00:00

bsakaguchi commented

2026-10-15 18:23:03 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 9, 2026):

Native macOS maintenance verification passed same-session reuse, explicit document disposal, and rejection of a second live owner while preserving the first document (https://github.com/morluto/rea/actions/runs/37824608002; production source 0e0df741). This establishes those lifecycle boundaries. The original multi-window scenario across separate clients/disconnects remains unverified; keeping this open for its exact session topology, calls and REA/Hopper versions.

@N0zoM1z0 commented on GitHub (Oct 9, 2026): Native macOS maintenance verification passed same-session reuse, explicit document disposal, and rejection of a second live owner while preserving the first document (https://github.com/morluto/rea/actions/runs/37824608002; production source 0e0df741). This establishes those lifecycle boundaries. The original multi-window scenario across separate clients/disconnects remains unverified; keeping this open for its exact session topology, calls and REA/Hopper versions.

bsakaguchi commented

2026-10-15 18:23:03 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 9, 2026):

CLI/MCP follow-up: reproduced a separate Linux 6.4.2 failure where a competing startup returned unavailable but still forwarded its same/different target into the first Hopper application. #1158 reserves the Linux application before launch. The final installed package passed competing CLI/MCP isolation, repeated opens, reconnect, target switching, cancellation/recovery, and owned-process cleanup. The owning document list stayed unchanged.

This does not establish macOS GUI window reuse after a session closes; keeping that original GUI facet open.

@N0zoM1z0 commented on GitHub (Oct 9, 2026): CLI/MCP follow-up: reproduced a separate Linux 6.4.2 failure where a competing startup returned unavailable but still forwarded its same/different target into the first Hopper application. #1158 reserves the Linux application before launch. The final installed package passed competing CLI/MCP isolation, repeated opens, reconnect, target switching, cancellation/recovery, and owned-process cleanup. The owning document list stayed unchanged. This does not establish macOS GUI window reuse after a session closes; keeping that original GUI facet open.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:12:21 +00:00

[PR #255] [MERGED] feat(electron): reconcile static artifacts with passive runtime #1903

bsakaguchi commented

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

Author

Owner

@Lancelotbronner commented on GitHub (Oct 25, 2026):

I have an existing .hop file with some manual work already done. How can the agent specifically open that database with REA?

@Lancelotbronner commented on GitHub (Oct 25, 2026): I have an existing .hop file with some manual work already done. How can the agent specifically open _that_ database with REA?

bsakaguchi commented

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

Author

Owner

@Lancelotbronner commented on GitHub (Oct 25, 2026):

Alternatively, Hopper already has an MCP server available. Could REA instead use it directly?

@Lancelotbronner commented on GitHub (Oct 25, 2026): Alternatively, Hopper already has an MCP server available. Could REA instead use it directly?

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

No description provided.

Rows
Columns