morluto/rea

Fork 0

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

[GH-ISSUE #494] Investigate Hopper remaining on Executing Python Script overlay #267

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Observation

A macOS Hopper session opened on Denver.hop shows a persistent Executing Python Script... overlay with a Cancel button. In the same screenshot, Hopper's log reports:

Background analysis ended in 0'32
Executing Python script "/tmp/rea-mGnswv/bootstrap.py"
.../rea-agents/bridge/hopper_bridge.py:12: DeprecationWarning: module 'sre_parse' is deprecated
  import sre_parse

The screenshot establishes that the overlay appeared after Hopper's background analysis completed and that the bridge bootstrap emitted a Python deprecation warning. It does not establish whether the script was still working or the overlay had become stale.

Investigation

Reproduce the macOS Hopper bridge startup path and determine whether bootstrap is waiting on bridge readiness, a queued API call, or a UI completion callback.
Trace how bootstrap completion, failure, timeout, and cancellation update Hopper's progress overlay.
Check whether cancellation cleans up the temporary bootstrap and bridge process/session state.
Assess replacing or safely suppressing the deprecated sre_parse import warning; keep this warning separate from actual bootstrap failures.

Acceptance criteria

A completed or failed bootstrap always clears the executing overlay and reports a useful readiness/error state.
A stalled bootstrap has an observable stage and bounded, actionable timeout behavior.
Cancelling the operation leaves no orphaned bridge/bootstrap state.
The deprecation warning is either removed safely or documented without obscuring bridge errors.

Evidence

User-provided Hopper screenshot, showing Denver.hop, the Executing Python Script... overlay, the bootstrap.py invocation, and the sre_parse deprecation warning. The screenshot is retained in the originating conversation; no claim is made here that the warning caused the apparent stall.

Originally created by @morluto on GitHub (Oct 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/494 ## Observation A macOS Hopper session opened on `Denver.hop` shows a persistent `Executing Python Script...` overlay with a Cancel button. In the same screenshot, Hopper's log reports: ```text Background analysis ended in 0'32 Executing Python script "/tmp/rea-mGnswv/bootstrap.py" .../rea-agents/bridge/hopper_bridge.py:12: DeprecationWarning: module 'sre_parse' is deprecated import sre_parse ``` The screenshot establishes that the overlay appeared after Hopper's background analysis completed and that the bridge bootstrap emitted a Python deprecation warning. It does not establish whether the script was still working or the overlay had become stale. ## Investigation - Reproduce the macOS Hopper bridge startup path and determine whether bootstrap is waiting on bridge readiness, a queued API call, or a UI completion callback. - Trace how bootstrap completion, failure, timeout, and cancellation update Hopper's progress overlay. - Check whether cancellation cleans up the temporary bootstrap and bridge process/session state. - Assess replacing or safely suppressing the deprecated `sre_parse` import warning; keep this warning separate from actual bootstrap failures. ## Acceptance criteria - A completed or failed bootstrap always clears the executing overlay and reports a useful readiness/error state. - A stalled bootstrap has an observable stage and bounded, actionable timeout behavior. - Cancelling the operation leaves no orphaned bridge/bootstrap state. - The deprecation warning is either removed safely or documented without obscuring bridge errors. ## Evidence User-provided Hopper screenshot, showing `Denver.hop`, the `Executing Python Script...` overlay, the `bootstrap.py` invocation, and the `sre_parse` deprecation warning. The screenshot is retained in the originating conversation; no claim is made here that the warning caused the apparent stall.

bsakaguchi

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

closed this issue
added the
P3: low

area: bridge

bug
labels

bsakaguchi commented

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

Author

Owner

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

Maintenance verification: official Hopper Demo 6.6.0 on native macOS passed the CLI/MCP fixture analysis and explicit close/shutdown checks for production source 0e0df741 (https://github.com/morluto/rea/actions/runs/37824608002). The bridge intentionally runs a long-lived Python request loop while connected, so the overlay during a responsive session alone does not prove a stall. The original Denver.hop flow and pressing Hopper's GUI Cancel remain unverified; this stays open pending the exact call sequence and REA/Hopper versions.

@N0zoM1z0 commented on GitHub (Oct 9, 2026): Maintenance verification: official Hopper Demo 6.6.0 on native macOS passed the CLI/MCP fixture analysis and explicit close/shutdown checks for production source 0e0df741 (https://github.com/morluto/rea/actions/runs/37824608002). The bridge intentionally runs a long-lived Python request loop while connected, so the overlay during a responsive session alone does not prove a stall. The original Denver.hop flow and pressing Hopper's GUI Cancel remain unverified; this stays open pending the exact call sequence and REA/Hopper versions.

bsakaguchi commented

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

Author

Owner

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

CLI/MCP investigation with official Linux Hopper 6.4.2: the final package in #1158 passed repeated requests, cancellation/recovery, target switching, and complete owned-process cleanup with empty bridge/server stderr. The bridge intentionally remains in its request loop while the session is active, so an executing-script overlay alone does not establish a stalled startup. The deprecated sre_parse import is absent from the current bridge.

GUI overlay completion and the Hopper GUI Cancel button were not verified from this VPS. Keeping this issue open for that GUI-specific behavior; #1158 fixes the independently reproduced Linux CLI startup-isolation problem.

@N0zoM1z0 commented on GitHub (Oct 9, 2026): CLI/MCP investigation with official Linux Hopper 6.4.2: the final package in #1158 passed repeated requests, cancellation/recovery, target switching, and complete owned-process cleanup with empty bridge/server stderr. The bridge intentionally remains in its request loop while the session is active, so an executing-script overlay alone does not establish a stalled startup. The deprecated sre_parse import is absent from the current bridge. GUI overlay completion and the Hopper GUI Cancel button were not verified from this VPS. Keeping this issue open for that GUI-specific behavior; #1158 fixes the independently reproduced Linux CLI startup-isolation problem.

bsakaguchi commented

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

Author

Owner

@suninrain086 commented on GitHub (Oct 13, 2026):

Another macOS reproduction: the overlay persists because the MCP client keeps the bridge connected and the agent never calls close_binary

Versions

REA 6.4.0 (npm), registered via rea setup --client opencode
Hopper Disassembler 6.6.0, macOS 27.0 (26A428), arm64 (Mac Studio M3 Ultra)
Client: OpenCode desktop 2.0.27 (MCP servers are hosted by its long-lived background service opencode-cli serve --service)
Model: local DeepSeek-V4-Flash-0731 (MLX), OpenAI-compatible endpoint

Sequence

In OpenCode, asked the agent to analyze a native Mac app. Hopper launched through the vendor launcher, and bootstrap.py started the bridge. The analysis worked and produced an Evidence bundle (32 records: 30 observed, 2 derived).
Operations recorded in the exported bundle, in bundle order: search_procedures×10 → procedure_pseudo_code×2 → search_procedures → binary_overview → procedure_pseudo_code → resolve_containing_procedure → search_procedures → get_objc_classes → search_procedures×3 → procedure_pseudo_code×2 → search_procedures×6 → list_strings → search_procedures×2.
The agent ended its turn without calling close_binary.
Hopper's background analysis log had finished, but the Executing Python Script... overlay with Cancel stayed up indefinitely.

What was holding the bridge

lsof -U showed Hopper (pid 4527) listening on /tmp/rea-kFI1S4/bridge.sock, with exactly one connected peer: node …/bin/rea mcp (pid 3894).
The parent of pid 3894 was …/ai.opencode.desktop/cli/2.0.27/opencode-cli serve --service, which is OpenCode's background service and outlives individual chats.

So in this case the overlay was not a stalled bootstrap. The bridge loop in bridge/hopper_bridge.py _run() was correctly serving a still-connected client: no idle timeout applies while connected, and the 30 s reconnect timeout only starts after a disconnect. The session would only end on close_binary/target switch, or when the MCP process exits (src/main/shutdown.ts detaches with retainProviderDocuments: true).

How it ended: In the same OpenCode chat, I asked the agent to call close_binary.

It called close_binary({ snapshot_path, overwrite: true }), which completed in about 0.4 s and returned the snapshot receipt (evidence_records: 32, primitive_entries: 6, workflow_entries: 2).
The overlay cleared, and /tmp/rea-kFI1S4 was removed, so explicit close worked as documented. I quit Hopper manually afterwards.
I did not press the GUI Cancel button, so that path is still unverified here.
An older runtime root from an earlier failed launch (Apple-events denial), /tmp/rea-xyO3Wr, is still present.

Why this is likely common across clients

The only instruction to close is the last line of the bundled skill ("Close an opened native session with close_binary when the investigation is complete"). The MCP server instructions and the open_binary/close_binary descriptions do not tell the agent to close when finished. Agents that don't load the skill, or that stop mid-task, leave the session open.
The overlay then lasts as long as the client keeps the MCP process alive:
- Claude Code: until the session exits
- Claude Desktop: until the app quits
- OpenCode: until its background service restarts, which in practice is indefinitely
During that time the Hopper GUI is blocked by the modal, which looks like a hang to users.

Possible directions (not proposing a specific fix)

Put the close-when-finished guidance in the server instructions and/or the open_binary result, so it does not depend on the skill.
Optionally release the Hopper Python thread after a bounded idle period with no requests, while keeping the target lease so the next request can reattach or report a clear state. I understand this conflicts with the current "no idle timeout while connected" behavior, so it may need a design decision.
Document in the Hopper section that the overlay is expected while a client is connected, and that close_binary is the way to clear it (not the GUI Cancel button).

@suninrain086 commented on GitHub (Oct 13, 2026): **Another macOS reproduction: the overlay persists because the MCP client keeps the bridge connected and the agent never calls `close_binary`** **Versions** - REA 6.4.0 (npm), registered via `rea setup --client opencode` - Hopper Disassembler 6.6.0, macOS 27.0 (26A428), arm64 (Mac Studio M3 Ultra) - Client: OpenCode desktop 2.0.27 (MCP servers are hosted by its long-lived background service `opencode-cli serve --service`) - Model: local DeepSeek-V4-Flash-0731 (MLX), OpenAI-compatible endpoint **Sequence** 1. In OpenCode, asked the agent to analyze a native Mac app. Hopper launched through the vendor launcher, and `bootstrap.py` started the bridge. The analysis worked and produced an Evidence bundle (32 records: 30 `observed`, 2 `derived`). 2. Operations recorded in the exported bundle, in bundle order: `search_procedures×10 → procedure_pseudo_code×2 → search_procedures → binary_overview → procedure_pseudo_code → resolve_containing_procedure → search_procedures → get_objc_classes → search_procedures×3 → procedure_pseudo_code×2 → search_procedures×6 → list_strings → search_procedures×2`. 3. The agent ended its turn without calling `close_binary`. 4. Hopper's background analysis log had finished, but the `Executing Python Script...` overlay with Cancel stayed up indefinitely. **What was holding the bridge** - `lsof -U` showed Hopper (pid 4527) listening on `/tmp/rea-kFI1S4/bridge.sock`, with exactly one connected peer: `node …/bin/rea mcp` (pid 3894). - The parent of pid 3894 was `…/ai.opencode.desktop/cli/2.0.27/opencode-cli serve --service`, which is OpenCode's background service and outlives individual chats. So in this case the overlay was not a stalled bootstrap. The bridge loop in `bridge/hopper_bridge.py` `_run()` was correctly serving a still-connected client: no idle timeout applies while connected, and the 30 s reconnect timeout only starts after a disconnect. The session would only end on `close_binary`/target switch, or when the MCP process exits (`src/main/shutdown.ts` detaches with `retainProviderDocuments: true`). **How it ended:** In the same OpenCode chat, I asked the agent to call `close_binary`. - It called `close_binary({ snapshot_path, overwrite: true })`, which completed in about 0.4 s and returned the snapshot receipt (`evidence_records: 32`, `primitive_entries: 6`, `workflow_entries: 2`). - The overlay cleared, and `/tmp/rea-kFI1S4` was removed, so explicit close worked as documented. I quit Hopper manually afterwards. - I did not press the GUI Cancel button, so that path is still unverified here. - An older runtime root from an earlier failed launch (Apple-events denial), `/tmp/rea-xyO3Wr`, is still present. **Why this is likely common across clients** - The only instruction to close is the last line of the bundled skill ("Close an opened native session with `close_binary` when the investigation is complete"). The MCP server `instructions` and the `open_binary`/`close_binary` descriptions do not tell the agent to close when finished. Agents that don't load the skill, or that stop mid-task, leave the session open. - The overlay then lasts as long as the client keeps the MCP process alive: - Claude Code: until the session exits - Claude Desktop: until the app quits - OpenCode: until its background service restarts, which in practice is indefinitely - During that time the Hopper GUI is blocked by the modal, which looks like a hang to users. **Possible directions (not proposing a specific fix)** - Put the close-when-finished guidance in the server `instructions` and/or the `open_binary` result, so it does not depend on the skill. - Optionally release the Hopper Python thread after a bounded idle period with no requests, while keeping the target lease so the next request can reattach or report a clear state. I understand this conflicts with the current "no idle timeout while connected" behavior, so it may need a design decision. - Document in the Hopper section that the overlay is expected while a client is connected, and that `close_binary` is the way to clear it (not the GUI Cancel button).

bsakaguchi commented

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

Author

Owner

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

The reported overlay is explained by the bridge still serving a connected MCP client. The latest macOS/OpenCode report confirms that the long-lived client remained connected after the agent turn ended; calling close_binary in the same chat completed in about 0.4 seconds, cleared the overlay, and removed the temporary runtime root (https://github.com/morluto/rea/issues/494#issuecomment-6141474592).

Current MCP server and open_binary/close_binary instructions tell agents to call close_binary when the investigation is finished. The Hopper guide now documents that the overlay can remain while the MCP connection is active and that explicit close is the supported cleanup path. The bridge is intentionally not idle-closed while the client remains connected, so the screenshot alone does not establish a stalled bootstrap.

The Hopper GUI Cancel button remains unverified; this issue does not claim that path works. No remaining REA defect is established by the reported connected-session behavior, so this report can close as clarified expected behavior and guidance. Reopen with a trace if the overlay remains after a successful close_binary or appears while no REA bridge connection is active.

@morluto commented on GitHub (Oct 14, 2026): The reported overlay is explained by the bridge still serving a connected MCP client. The latest macOS/OpenCode report confirms that the long-lived client remained connected after the agent turn ended; calling `close_binary` in the same chat completed in about 0.4 seconds, cleared the overlay, and removed the temporary runtime root (https://github.com/morluto/rea/issues/494#issuecomment-6141474592). Current MCP server and `open_binary`/`close_binary` instructions tell agents to call `close_binary` when the investigation is finished. The Hopper guide now documents that the overlay can remain while the MCP connection is active and that explicit close is the supported cleanup path. The bridge is intentionally not idle-closed while the client remains connected, so the screenshot alone does not establish a stalled bootstrap. The Hopper GUI Cancel button remains unverified; this issue does not claim that path works. No remaining REA defect is established by the reported connected-session behavior, so this report can close as clarified expected behavior and guidance. Reopen with a trace if the overlay remains after a successful `close_binary` or appears while no REA bridge connection is active.

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:34 +00:00

[PR #285] [MERGED] feat: add managed characterization and reconstruction coverage #1927