[GH-ISSUE #7727] fix(hopper): admit macOS arguments before application handoff #4625

New issue

Closed

opened 2026-10-31 00:51:32 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:51:32 +00:00

Owner

Originally created by @gensokyo-dev on GitHub (Oct 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7727

Before submitting

Searched related open and closed issues and PRs.
Removed credentials and private target data.

Area / interface / earliest stage

Provider startup; CLI/MCP; macOS application handoff.

Observed behavior

Source-derived at 2b8fb387b6: HopperApplicationLauncher.#launchPreparedTarget starts the helper before checking whether its arguments can be represented by the vendor AppleScript handoff. The existing character check only controls authorizationDenialBeforeHandoff, a later diagnostic fact.

Reproduction and evidence

Inspected src/hopper/BridgeLauncher.ts and the consumer in src/hopper/HopperClient.ts. NOT_ENOUGH_INFO for actual Hopper runtime behavior at issue creation: the development host is Linux and the pinned public DMG download returned HTTP 403. Native macOS verification is proposed. No runtime exploit or target execution is claimed.

Expected behavior

Preserve caller-selected file identities and evidence. Admit the final launcher arguments before starting the application; where the handoff cannot represent an argument literally, return a clear typed refusal before handoff. Executable targets may already use an owned prepared-image path, so validating the original basename globally would be incorrect.

Impact and scope

macOS Hopper launch argument interpretation. Actual vendor-helper impact and frequency remain unverified. Linux launchers and archive filename policy are outside this issue.

Version / runtime / target

Source 2b8fb387; Node 24.22.1; Linux x64 development host. macOS Hopper launcher, executable or database target.

Typed outcome and checks

A refused launch should retain its reason, avoid application handoff, remove the token-bearing bootstrap, release its lease, and keep cleanup failures retryable. Regression checks should distinguish final prepared-image paths from original target paths and verify native macOS behavior.

Originally created by @gensokyo-dev on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7727 ### Before submitting - [x] Searched related open and closed issues and PRs. - [x] Removed credentials and private target data. ### Area / interface / earliest stage Provider startup; CLI/MCP; macOS application handoff. ### Observed behavior Source-derived at 2b8fb387b6d1204f6c6e8abb89d075b7d95ba402: `HopperApplicationLauncher.#launchPreparedTarget` starts the helper before checking whether its arguments can be represented by the vendor AppleScript handoff. The existing character check only controls `authorizationDenialBeforeHandoff`, a later diagnostic fact. ### Reproduction and evidence Inspected `src/hopper/BridgeLauncher.ts` and the consumer in `src/hopper/HopperClient.ts`. NOT_ENOUGH_INFO for actual Hopper runtime behavior at issue creation: the development host is Linux and the pinned public DMG download returned HTTP 403. Native macOS verification is proposed. No runtime exploit or target execution is claimed. ### Expected behavior Preserve caller-selected file identities and evidence. Admit the final launcher arguments before starting the application; where the handoff cannot represent an argument literally, return a clear typed refusal before handoff. Executable targets may already use an owned prepared-image path, so validating the original basename globally would be incorrect. ### Impact and scope macOS Hopper launch argument interpretation. Actual vendor-helper impact and frequency remain unverified. Linux launchers and archive filename policy are outside this issue. ### Version / runtime / target Source 2b8fb387; Node 24.22.1; Linux x64 development host. macOS Hopper launcher, executable or database target. ### Typed outcome and checks A refused launch should retain its reason, avoid application handoff, remove the token-bearing bootstrap, release its lease, and keep cleanup failures retryable. Regression checks should distinguish final prepared-image paths from original target paths and verify native macOS behavior.

bsakaguchi closed this issue

2026-10-31 00:51:32 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:43 +00:00

[PR #4649] [CLOSED] docs(omp): distinguish configuration root and agent override paths #6342