[GH-ISSUE #7362] [Bug] Opening a directory .app bundle whose executable is a name-classified artifact fails since c27560e43 #4373

Closed
opened 2026-10-31 00:49:18 +00:00 by bsakaguchi · 2 comments
Owner

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

Area: Evidence, artifacts, or reconstruction · Interface: MCP (also CLI) · Earliest failure stage: Setup or provider admission
REA version: source 15a8f6847 (also fails on a905a71e3)
Runtime and platform: Node 24.22.1; macOS 26.5.2 arm64 (local); ubuntu GitHub-hosted runners (CI)

Observed behavior

open_binary / inspect_artifact / compare_artifacts on a directory bundle (l.app/ with Contents/Info.plist CFBundleExecutable=main.js) is refused with target_unavailable / unsupported_target: "Cannot open artifact: unsupported binary format."

Failing tests (local at 15a8f6847 and Linux CI, e.g. run 40423258926 shards 1 and 4):

  • tests/acceptance/applications/artifactComparisonCoverage.test.ts › retains traversal uncertainty when a directory omits special filesystem entries
  • tests/boundary/mcp/artifactInspectionCoverageMcp.test.ts › derives inspection and summary coverage from inventory traversal (FIFO: true / false)

Reproduction

  1. git checkout 15a8f6847 && npm ci && npm run test:focused -- tests/boundary/mcp/artifactInspectionCoverageMcp.test.ts tests/acceptance/applications/artifactComparisonCoverage.test.ts → 3 failed.
  2. Same at 3515b2622 (parent of c27560e43) → pass. git bisect between a7f50e338 and ace4dbf36: first bad commit c27560e43 fix(artifacts): classify selected package names.

Expected behavior

A directory bundle resolves to its CFBundleExecutable and is classified by the executable's own name (behavior at 3515b2622), and the bundle facts (bundleInfoPlist) reach the artifact target so admitted-source checks compare the right file.

Impact and scope

Any directory bundle whose executable is a name-classified artifact (JavaScript, plist, source map, ASAR). Mach-O bundles are unaffected because they skip name classification. Real-world frequency unknown (Electron apps ship Mach-O executables); the repository's own fixtures hit it.

Relevant output or evidence

  • src/domain/artifactNameSelection.ts:18-26 artifactNameForClassification(selectedPath, canonicalPath) returns the caller-selected spelling when it ends in .app|.pkg|.dmg (HarmonyOS App Pack, src/domain/zipPackageFormat.ts:126-132).
  • src/application/BinaryTargetResolver.ts:157-173 resolves the .app directory to its executable via resolveAppBundle but keeps selectedPath = the directory; line 379 therefore classifies main.js by the name …/l.app → namedArtifactFormat undefined → readExecutableMetadata on JavaScript text → file_format_rejected.
  • Second blocker (source-derived, verified by a worktree experiment): with classification fixed, inspect_artifact fails with integrity_mismatch "The opened file was replaced by a directory". 2dd2ffcd4 sets expectedRootSha256 whenever bundleInfoPlist === undefined (src/artifacts/ArtifactProvider.ts), and the resolver's artifact branch (BinaryTargetResolver.ts:396-404) never spreads ...bundle (the executable branches at 286/337/369/446 do), so artifact-kind bundle targets have never carried bundleInfoPlist; 2dd2ffcd4 made that omission fatal.

Analysis or suspected cause

Source-derived, both points confirmed by running the two test files with a two-line patch (classify by bundleInfoPlist === undefined ? selectedPath : path; spread ...bundle into the artifact identity) → all 3 pass. Whether the ownership-correct fix is instead to hand readOpenedBinaryTarget the executable spelling when resolveAppBundle changed the path is for review.

Additional context

I will open a PR for this. Last known good 3515b2622; first known bad c27560e43 (second blocker 2dd2ffcd4).

Originally created by @chordpli on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7362 Area: Evidence, artifacts, or reconstruction · Interface: MCP (also CLI) · Earliest failure stage: Setup or provider admission **REA version:** source `15a8f6847` (also fails on `a905a71e3`) **Runtime and platform:** Node 24.22.1; macOS 26.5.2 arm64 (local); ubuntu GitHub-hosted runners (CI) ### Observed behavior `open_binary` / `inspect_artifact` / `compare_artifacts` on a directory bundle (`l.app/` with `Contents/Info.plist` `CFBundleExecutable=main.js`) is refused with `target_unavailable` / `unsupported_target`: "Cannot open artifact: unsupported binary format." Failing tests (local at 15a8f6847 and Linux CI, e.g. run 40423258926 shards 1 and 4): - `tests/acceptance/applications/artifactComparisonCoverage.test.ts` › retains traversal uncertainty when a directory omits special filesystem entries - `tests/boundary/mcp/artifactInspectionCoverageMcp.test.ts` › derives inspection and summary coverage from inventory traversal (FIFO: true / false) ### Reproduction 1. `git checkout 15a8f6847 && npm ci && npm run test:focused -- tests/boundary/mcp/artifactInspectionCoverageMcp.test.ts tests/acceptance/applications/artifactComparisonCoverage.test.ts` → 3 failed. 2. Same at 3515b2622 (parent of c27560e43) → pass. `git bisect` between a7f50e338 and ace4dbf36: first bad commit c27560e43 `fix(artifacts): classify selected package names`. ### Expected behavior A directory bundle resolves to its `CFBundleExecutable` and is classified by the executable's own name (behavior at 3515b2622), and the bundle facts (`bundleInfoPlist`) reach the artifact target so admitted-source checks compare the right file. ### Impact and scope Any directory bundle whose executable is a name-classified artifact (JavaScript, plist, source map, ASAR). Mach-O bundles are unaffected because they skip name classification. Real-world frequency unknown (Electron apps ship Mach-O executables); the repository's own fixtures hit it. ### Relevant output or evidence - `src/domain/artifactNameSelection.ts:18-26` `artifactNameForClassification(selectedPath, canonicalPath)` returns the caller-selected spelling when it ends in `.app|.pkg|.dmg` (HarmonyOS App Pack, `src/domain/zipPackageFormat.ts:126-132`). - `src/application/BinaryTargetResolver.ts:157-173` resolves the `.app` directory to its executable via `resolveAppBundle` but keeps `selectedPath` = the directory; line 379 therefore classifies `main.js` by the name `…/l.app` → `namedArtifactFormat` undefined → `readExecutableMetadata` on JavaScript text → `file_format_rejected`. - Second blocker (source-derived, verified by a worktree experiment): with classification fixed, `inspect_artifact` fails with `integrity_mismatch` "The opened file was replaced by a directory". 2dd2ffcd4 sets `expectedRootSha256` whenever `bundleInfoPlist === undefined` (`src/artifacts/ArtifactProvider.ts`), and the resolver's artifact branch (`BinaryTargetResolver.ts:396-404`) never spreads `...bundle` (the executable branches at 286/337/369/446 do), so artifact-kind bundle targets have never carried `bundleInfoPlist`; 2dd2ffcd4 made that omission fatal. ### Analysis or suspected cause Source-derived, both points confirmed by running the two test files with a two-line patch (classify by `bundleInfoPlist === undefined ? selectedPath : path`; spread `...bundle` into the artifact identity) → all 3 pass. Whether the ownership-correct fix is instead to hand `readOpenedBinaryTarget` the executable spelling when `resolveAppBundle` changed the path is for review. ### Additional context I will open a PR for this. Last known good 3515b2622; first known bad c27560e43 (second blocker 2dd2ffcd4).
Author
Owner

@chordpli commented on GitHub (Oct 27, 2026):

I am working on a fix PR for this: classify a resolved bundle's executable by its own canonical name in BinaryTargetResolver, and carry the bundle facts (bundleInfoPlist) on artifact-kind targets so the admitted-source digest check compares the executable rather than the directory. The two failing tests stay as regressions and I will add a unit case for a directory bundle with CFBundleExecutable=main.js.

<!-- gh-comment-id:6431792594 --> @chordpli commented on GitHub (Oct 27, 2026): I am working on a fix PR for this: classify a resolved bundle's executable by its own canonical name in `BinaryTargetResolver`, and carry the bundle facts (`bundleInfoPlist`) on artifact-kind targets so the admitted-source digest check compares the executable rather than the directory. The two failing tests stay as regressions and I will add a unit case for a directory bundle with `CFBundleExecutable=main.js`.
Author
Owner

@chordpli commented on GitHub (Oct 27, 2026):

Status at main a95b83c2b: #7349 (1201c2554) changed the artifactInspectionCoverageMcp fixture from a main.js executable to a Mach-O main, so that test and artifactComparisonCoverage pass on main now, but the refusal itself is unchanged. The bundle cases added in #7365 (tests/boundary/filesystem/artifactSelectedName.test.ts) still fail on unmodified main a95b83c2b: 2 failed, "Cannot open artifact: unsupported binary format" for a bundle whose CFBundleExecutable is main.js.

<!-- gh-comment-id:6445353292 --> @chordpli commented on GitHub (Oct 27, 2026): Status at `main` a95b83c2b: #7349 (1201c2554) changed the `artifactInspectionCoverageMcp` fixture from a `main.js` executable to a Mach-O `main`, so that test and `artifactComparisonCoverage` pass on `main` now, but the refusal itself is unchanged. The bundle cases added in #7365 (`tests/boundary/filesystem/artifactSelectedName.test.ts`) still fail on unmodified `main` a95b83c2b: 2 failed, "Cannot open artifact: unsupported binary format" for a bundle whose `CFBundleExecutable` is `main.js`.
Sign in to join this conversation.
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#4373
No description provided.