morluto/rea

Fork 0

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

sharingd; failed launch leaves poisoned session #607

New issue

Closed

opened 2026-10-15 18:26:36 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 18:26:36 +00:00

Owner

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

Before submitting

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

Area

MCP or agent integration

Observed behavior

Environment: macOS 27.0.1 (26A434), Apple Silicon, REA 6.4.0, Node 22.23.1, Hopper Disassembler 6.6.0-demo, MCP server started from Claude Desktop.

Launcher exit 2 "Not authorized to send Apple events to Hopper Disassembler" when the MCP server is spawned through Claude's disclaimer helper; the same launch works from a normal shell.
After a failed open_binary the session is reused: every later call returns unreadable_output, close_binary returns cleanup_incomplete, and only killing the MCP server clears it (target stays "already open in REA session").
unreadable_output hides the real cause; only binary_session shows the ProviderAdapterError ... failed during open_binary.
CLI rea analyze /usr/libexec/sharingd: launcher exits 0, Hopper sits at ~100% CPU, then provider_timeout after the hard-coded 120 s (HopperClient startupTimeoutMs, no env override). With a longer timeout Hopper itself crashed with EXC_BAD_ACCESS / SIGSEGV (crash report available).

Expected: a diagnosable error, a session that recovers after a failed open, and a configurable Hopper startup timeout.

Related: #494, #478, #479.

Reproduction

Install rea-agents 6.4.0 on macOS with Hopper Disassembler 6.6.0-demo.
Run: rea analyze /usr/libexec/sharingd
Hopper launches (launcher exit 0), sits at ~100% CPU, and REA returns provider_timeout after the hard-coded 120 s startup timeout.
Raise startupTimeoutMs in dist/hopper/HopperClient.js (120000 -> 900000) and repeat: Hopper itself crashes with EXC_BAD_ACCESS / SIGSEGV.
Via MCP (Claude Desktop): open_binary fails once, then every later call returns unreadable_output and close_binary returns cleanup_incomplete until the MCP server process is killed.

Expected behavior

Hopper failures surface a typed, diagnosable error (not unreadable_output) that names the real cause, e.g. the ProviderAdapterError from open_binary.
A failed open_binary leaves no poisoned session: the next open_binary or close_binary recovers and cleanup is confirmed.
The Hopper startup timeout is configurable (like REA_GHIDRA_STARTUP_TIMEOUT_MS for Ghidra).
A Hopper crash is reported as a provider crash with a clear next step.

Impact and scope

Affects the Hopper provider on macOS 27 / Apple Silicon, at least for large system binaries such as sharingd, and MCP session recovery after any failed open. Recovery is impaired: the session ownership guard blocks reopening the same target and only killing the MCP server clears it. The Ghidra provider was not tested. No evidence-integrity impact observed. Related: #494, #478, #479.

REA version

6.4.0 (rea-agents from npm)

Runtime and platform

Node 22.23.1; macOS 27.0.1 (26A434) arm64 (Apple Silicon); Hopper Disassembler 6.6.0-demo

Target and artifact context

Mach-O arm64 system daemon (/usr/libexec/sharingd); Hopper provider

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

CLI: `rea analyze /usr/libexec/sharingd` -> provider_timeout after 120 s (Hopper at ~100% CPU, launcher exit 0).
MCP: binary_session -> ProviderAdapterError ... failed during open_binary; all other tools -> unreadable_output; close_binary -> cleanup_incomplete; reopen -> "already open in REA session <id>".
Launcher via Claude's disclaimer helper: exit 2 "Not authorized to send Apple events to Hopper Disassembler" (same launch works from a shell).
Crash: Hopper EXC_BAD_ACCESS / SIGSEGV on macOS 27.0.1 (crash report available on request).

Typed outcome or recovery expected

A typed provider_crashed / provider_timeout error with the underlying cause, and a cleaned-up session that can be reopened without restarting the MCP server.

Analysis or suspected cause

Source-derived: dist/domain/analysisErrorProjection.js uses unreadable_output as a generic fallback for protocol errors, and dist/hopper/HopperClient.js hard-codes startupTimeoutMs to 120_000 with no env override. Hypothesis (unverified): the SIGSEGV is a Hopper 6.6.0-demo bug on macOS 27 while analyzing sharingd, not a REA bug.

Additional context

Related issues: #494 (Hopper stuck on "Executing Python Script"), #478 (make Hopper provider failures diagnosable from MCP), #479 (reuse Hopper GUI windows). Suggested regression test: simulate a failed open_binary and assert the next open_binary/close_binary recovers the session.

Originally created by @CemRoot on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1808 ### 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 MCP or agent integration ### Observed behavior Environment: macOS 27.0.1 (26A434), Apple Silicon, REA 6.4.0, Node 22.23.1, Hopper Disassembler 6.6.0-demo, MCP server started from Claude Desktop. 1) Launcher exit 2 "Not authorized to send Apple events to Hopper Disassembler" when the MCP server is spawned through Claude's disclaimer helper; the same launch works from a normal shell. 2) After a failed open_binary the session is reused: every later call returns unreadable_output, close_binary returns cleanup_incomplete, and only killing the MCP server clears it (target stays "already open in REA session"). 3) unreadable_output hides the real cause; only binary_session shows the ProviderAdapterError ... failed during open_binary. 4) CLI `rea analyze /usr/libexec/sharingd`: launcher exits 0, Hopper sits at ~100% CPU, then provider_timeout after the hard-coded 120 s (HopperClient startupTimeoutMs, no env override). With a longer timeout Hopper itself crashed with EXC_BAD_ACCESS / SIGSEGV (crash report available). Expected: a diagnosable error, a session that recovers after a failed open, and a configurable Hopper startup timeout. Related: #494, #478, #479. ### Reproduction 1. Install rea-agents 6.4.0 on macOS with Hopper Disassembler 6.6.0-demo. 2. Run: rea analyze /usr/libexec/sharingd 3. Hopper launches (launcher exit 0), sits at ~100% CPU, and REA returns provider_timeout after the hard-coded 120 s startup timeout. 4. Raise startupTimeoutMs in dist/hopper/HopperClient.js (120000 -> 900000) and repeat: Hopper itself crashes with EXC_BAD_ACCESS / SIGSEGV. 5. Via MCP (Claude Desktop): open_binary fails once, then every later call returns unreadable_output and close_binary returns cleanup_incomplete until the MCP server process is killed. ### Expected behavior - Hopper failures surface a typed, diagnosable error (not unreadable_output) that names the real cause, e.g. the ProviderAdapterError from open_binary. - A failed open_binary leaves no poisoned session: the next open_binary or close_binary recovers and cleanup is confirmed. - The Hopper startup timeout is configurable (like REA_GHIDRA_STARTUP_TIMEOUT_MS for Ghidra). - A Hopper crash is reported as a provider crash with a clear next step. ### Impact and scope Affects the Hopper provider on macOS 27 / Apple Silicon, at least for large system binaries such as sharingd, and MCP session recovery after any failed open. Recovery is impaired: the session ownership guard blocks reopening the same target and only killing the MCP server clears it. The Ghidra provider was not tested. No evidence-integrity impact observed. Related: #494, #478, #479. ### REA version 6.4.0 (rea-agents from npm) ### Runtime and platform Node 22.23.1; macOS 27.0.1 (26A434) arm64 (Apple Silicon); Hopper Disassembler 6.6.0-demo ### Target and artifact context Mach-O arm64 system daemon (/usr/libexec/sharingd); Hopper provider ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence ```text CLI: `rea analyze /usr/libexec/sharingd` -> provider_timeout after 120 s (Hopper at ~100% CPU, launcher exit 0). MCP: binary_session -> ProviderAdapterError ... failed during open_binary; all other tools -> unreadable_output; close_binary -> cleanup_incomplete; reopen -> "already open in REA session <id>". Launcher via Claude's disclaimer helper: exit 2 "Not authorized to send Apple events to Hopper Disassembler" (same launch works from a shell). Crash: Hopper EXC_BAD_ACCESS / SIGSEGV on macOS 27.0.1 (crash report available on request). ``` ### Typed outcome or recovery expected A typed provider_crashed / provider_timeout error with the underlying cause, and a cleaned-up session that can be reopened without restarting the MCP server. ### Analysis or suspected cause Source-derived: dist/domain/analysisErrorProjection.js uses unreadable_output as a generic fallback for protocol errors, and dist/hopper/HopperClient.js hard-codes startupTimeoutMs to 120_000 with no env override. Hypothesis (unverified): the SIGSEGV is a Hopper 6.6.0-demo bug on macOS 27 while analyzing sharingd, not a REA bug. ### Additional context Related issues: #494 (Hopper stuck on "Executing Python Script"), #478 (make Hopper provider failures diagnosable from MCP), #479 (reuse Hopper GUI windows). Suggested regression test: simulate a failed open_binary and assert the next open_binary/close_binary recovers the session.

bsakaguchi

2026-10-15 18:26:36 +00:00

closed this issue
added the
area: native

P1: high

bug
labels

bsakaguchi commented

2026-10-15 18:26:36 +00:00

Author

Owner

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026):

Triage note: I couldn't reproduce this here because the macOS host has no Hopper installed, so I'm skipping it for now. Status on current main (c22111eca), from source only:

Configurable startup timeout: 069308bbe (Refs #1808) added REA_HOPPER_STARTUP_TIMEOUT_MS (documented in docs/installation.md) in place of the hard-coded 120 s.
Recovery after a failed open: the same commit preserves the primary startup failure and launcher diagnostics, and tests/acceptance/providers/hopperStartupRecovery.test.ts covers recovering a denied launch through the same stdio MCP session and the CLI.
Not verified: the Apple-events authorization denial under Claude Desktop's helper, and the Hopper 6.6.0-demo SIGSEGV on sharingd. Both need real macOS 27 + Hopper verification. The commit message says the same.

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026): Triage note: I couldn't reproduce this here because the macOS host has no Hopper installed, so I'm skipping it for now. Status on current main (c22111eca), from source only: - Configurable startup timeout: 069308bbe (Refs #1808) added `REA_HOPPER_STARTUP_TIMEOUT_MS` (documented in docs/installation.md) in place of the hard-coded 120 s. - Recovery after a failed open: the same commit preserves the primary startup failure and launcher diagnostics, and `tests/acceptance/providers/hopperStartupRecovery.test.ts` covers recovering a denied launch through the same stdio MCP session and the CLI. - Not verified: the Apple-events authorization denial under Claude Desktop's helper, and the Hopper 6.6.0-demo SIGSEGV on `sharingd`. Both need real macOS 27 + Hopper verification. The commit message says the same.

bsakaguchi commented

2026-10-15 18:26:37 +00:00

Author

Owner

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

Tested on current main (96fc84f) with Hopper Disassembler 6.6.0-demo on macOS 27.0.1 (arm64), Node 22.23.3.

REA_HOPPER_STARTUP_TIMEOUT_MS=900000 rea analyze /usr/libexec/sharingd completed successfully in about 5.5 min (25,821 procedures, 23,346 strings). The old 120 s provider_timeout is gone, and Hopper did not crash this time.
I could not reproduce the SIGSEGV on a fresh Hopper install, so it was probably an environment issue on my side.
Not yet verified: the Apple events authorization denial when REA is spawned through Claude Desktop's helper. I'll report back after testing the MCP path.

Thanks for the fix!

@CemRoot commented on GitHub (Oct 13, 2026): Tested on current `main` (96fc84f) with Hopper Disassembler 6.6.0-demo on macOS 27.0.1 (arm64), Node 22.23.3. - `REA_HOPPER_STARTUP_TIMEOUT_MS=900000 rea analyze /usr/libexec/sharingd` completed successfully in about 5.5 min (25,821 procedures, 23,346 strings). The old 120 s `provider_timeout` is gone, and Hopper did not crash this time. - I could not reproduce the SIGSEGV on a fresh Hopper install, so it was probably an environment issue on my side. - Not yet verified: the Apple events authorization denial when REA is spawned through Claude Desktop's helper. I'll report back after testing the MCP path. Thanks for the fix!

bsakaguchi commented

2026-10-15 18:26:37 +00:00

Author

Owner

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

Additional evidence from my report #3268:

Environment: rea-agents 6.4.0 (npm), Hopper Disassembler 6.6.0, macOS 27.0.1 arm64; tested through MCP and CLI.

The startup deadline appears to include initial analysis. Hopper documents --python as executing after initial analysis ends, and REA uses that option for bridge bootstrap. In the 6.4.0 distribution, HopperClient.js:95 defaults startupTimeoutMs to 120_000, while HopperProvider.js:150–178 does not override it.

On my approximately 10 MB arm64 Mach-O, REA returned provider_timeout with stage: startup and timeout_ms: 120000. Hopper continued analyzing and completed normally after approximately four minutes. A separate 75 KB binary succeeded through the same workflow. This supports analysis exceeding the startup deadline as a cause independent of the crash reported here.

The remediation suggested a loader or license dialog, although neither was present.

Requested improvements:

A configurable Hopper startup deadline, analogous to REA_GHIDRA_STARTUP_TIMEOUT_MS.
Timeout guidance that includes lengthy initial analysis.
A regression test covering delayed bridge registration after initial analysis.

Pre-analyzing and saving a .hop database allowed faster loading in my test. Recovery after terminating Hopper is tracked separately in #2975.

The original observations and distribution-file references remain in #3268. I am consolidating that report here.

@trigger2k20 commented on GitHub (Oct 14, 2026): Additional evidence from my report #3268: Environment: rea-agents 6.4.0 (npm), Hopper Disassembler 6.6.0, macOS 27.0.1 arm64; tested through MCP and CLI. The startup deadline appears to include initial analysis. Hopper documents --python as executing after initial analysis ends, and REA uses that option for bridge bootstrap. In the 6.4.0 distribution, HopperClient.js:95 defaults startupTimeoutMs to 120_000, while HopperProvider.js:150–178 does not override it. On my approximately 10 MB arm64 Mach-O, REA returned provider_timeout with stage: startup and timeout_ms: 120000. Hopper continued analyzing and completed normally after approximately four minutes. A separate 75 KB binary succeeded through the same workflow. This supports analysis exceeding the startup deadline as a cause independent of the crash reported here. The remediation suggested a loader or license dialog, although neither was present. Requested improvements: - A configurable Hopper startup deadline, analogous to REA_GHIDRA_STARTUP_TIMEOUT_MS. - Timeout guidance that includes lengthy initial analysis. - A regression test covering delayed bridge registration after initial analysis. Pre-analyzing and saving a .hop database allowed faster loading in my test. Recovery after terminating Hopper is tracked separately in #2975. The original observations and distribution-file references remain in #3268. I am consolidating that report here.

bsakaguchi commented

2026-10-15 18:26:37 +00:00

Author

Owner

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

The REA-owned startup and recovery problems reported here have been addressed. REA_HOPPER_STARTUP_TIMEOUT_MS now configures the Hopper startup deadline, including initial analysis and bridge readiness; the default remains 120 seconds. The failed-open path preserves the startup diagnostic, and tests/acceptance/providers/hopperStartupRecovery.test.ts covers denied-launch recovery through the same MCP session and CLI.

There is also a real current-main report from Hopper 6.6.0-demo on macOS 27.0.1 arm64: with a 900-second deadline, /usr/libexec/sharingd completed analysis in about 5.5 minutes, and the reported SIGSEGV did not recur (https://github.com/morluto/rea/issues/1808#issuecomment-6142073195). This is user runtime evidence, not a repository-host reproduction.

The original SIGSEGV and the Apple Events denial under Claude Desktop's disclaimer helper remain unverified on the affected setup. Current guidance explains how to grant Automation access; the recovery acceptance test uses a controlled denial fixture and does not reproduce Claude Desktop's TCC path. I found no remaining source-confirmed REA defect in this report. Please open a focused follow-up with the current REA/Hopper versions, exact helper sequence, and crash/authorization diagnostics if either behavior recurs after the fix. The GUI-host observations are not claimed as fixed or reproduced here.

@morluto commented on GitHub (Oct 14, 2026): The REA-owned startup and recovery problems reported here have been addressed. `REA_HOPPER_STARTUP_TIMEOUT_MS` now configures the Hopper startup deadline, including initial analysis and bridge readiness; the default remains 120 seconds. The failed-open path preserves the startup diagnostic, and `tests/acceptance/providers/hopperStartupRecovery.test.ts` covers denied-launch recovery through the same MCP session and CLI. There is also a real current-main report from Hopper 6.6.0-demo on macOS 27.0.1 arm64: with a 900-second deadline, `/usr/libexec/sharingd` completed analysis in about 5.5 minutes, and the reported SIGSEGV did not recur (https://github.com/morluto/rea/issues/1808#issuecomment-6142073195). This is user runtime evidence, not a repository-host reproduction. The original SIGSEGV and the Apple Events denial under Claude Desktop's disclaimer helper remain unverified on the affected setup. Current guidance explains how to grant Automation access; the recovery acceptance test uses a controlled denial fixture and does not reproduce Claude Desktop's TCC path. I found no remaining source-confirmed REA defect in this report. Please open a focused follow-up with the current REA/Hopper versions, exact helper sequence, and crash/authorization diagnostics if either behavior recurs after the fix. The GUI-host observations are not claimed as fixed or reproduced here.

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:14:21 +00:00

[PR #607] [MERGED] fix(managed): distinguish metadata handles from member accesses #2107