morluto/rea

Fork 0

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

[GH-ISSUE #4310] [Feature] Open nested Apple bundle directories (appex, framework, xpc, plug-in) as targets #1714

New issue

Open

opened 2026-10-16 21:09:21 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Originally assigned to: @kaoru0822-kitauji on GitHub.

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

Let open_binary, inspect_macho, inspect_signature, and inspect_plist (and their CLI commands) accept .appex, .framework, .xpc, .systemextension, .bundle, and .plugin directories. REA should resolve the program file through the bundle's Info.plist CFBundleExecutable, the way it resolves .app today, and add the macOS framework layout (Versions/Current/Resources/Info.plist, program file in Versions/Current/). Cases that cannot be resolved should fail closed with a typed reason. The rejection that Apple bundle directories receive today points the analyst to the JavaScript/Electron analyzer, which is misleading. This request replaces that message.

An analyst who inspects an app's extension, framework, or XPC service usually has the bundle directory, not the program file inside it. REA admits only one kind of directory: in resolveAppBundle, any directory whose extension is not .app is rejected with constraint directory_requires_file (BinaryTargetResolver.ts#L435-L451). Every target opened by open_binary, the CLI inspection commands, and the doctor target check passes through this resolver (BinaryTargetResolver.ts#L92-L97). The .app resolver itself knows only two layouts, Contents/Info.plist with Contents/MacOS/, and a flat root Info.plist (AppBundleExecutable.ts#L21-L37). It therefore has no route to a macOS framework's Versions/A/Resources/Info.plist.

The rejection message is fixed text that recommends the JavaScript analyzer for any non-.app directory (analysisErrorPresentation.ts#L266-L268). The remediation does the same (analysisErrorPresentation.ts#L80-L84). The CLI commands show the same text, even though the analyst never called open_binary.

Observed with npx -y rea-agents@6.5.0 (--version prints 6.5.0, release commit 3b79af28e80785afce9f5998d8f03289402a1847) on macOS 27.0.1 (26A434) arm64. rea inspect-macho, rea inspect-signature, and rea inspect-plist each exit 1 with the same error for three stock bundles: /System/Applications/Maps.app/Contents/PlugIns/MapsDiagnostic.appex, /System/Library/Frameworks/CreateML.framework, and /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc:

code: target_unavailable
category: unavailable
message: open_binary accepts files and macOS app bundles. This target is a directory; JavaScript/Electron application directories can be analyzed directly with analyze_javascript_application or `rea analyze <directory>`.
remediation:
  action: "For a JavaScript/Electron application directory, call analyze_javascript_application with input_path or run `rea analyze <directory>`. For binary analysis, select its executable file."
details:
  reason: this opening route requires a file or app bundle
  constraint: directory_requires_file

A self-built, ad-hoc-signed ./fixture/Demo.framework with the documented Versions/A layout fails the same way. codesign -dv reports it as Format=bundle with Mach-O thin (arm64), so Apple's own tool treats it as a bundle. When the framework's program file Versions/A/Demo is given to rea inspect-plist instead, the command looks for Versions/A/Contents/Info.plist and fails with capability_unavailable, because the default plist is Contents/Info.plist beside the program directory (NativeMacOSProvider.ts#L1153-L1166). The analyst must locate the program file and the plist by hand, and the resulting Evidence names a loose file rather than the bundle it came from.

Use cases

No response

Desired outcome and success criteria

Admission. A directory whose extension is .appex, .framework, .xpc, .systemextension, .bundle, or .plugin (case-insensitive) is opened like .app. Behavior for .app, including the iOS-on-Mac Wrapper layout, is unchanged.
Layouts. Resolution reads CFBundleExecutable from the bundle's Info.plist in the macOS Contents/ layout and the flat iOS-style root layout that REA already supports. For .framework, it also reads the macOS versioned layout: Info.plist at Versions/Current/Resources/Info.plist, program file Versions/Current/<CFBundleExecutable>. All symlinks, including Versions/Current and the root symlinks, must resolve inside the bundle, under the same containment rule .app uses. The flat root layout covers iOS-style frameworks and extensions.
Evidence. The subject remains the resolved program file, with its digest as today. The result records the bundle directory, the bundle type, the layout used, the Info.plist path, and, for a versioned framework, the version directory that Versions/Current selects. The default inspect_plist target is that Info.plist, and inspect_plist relative paths resolve from the bundle root.
Framework name. When a framework's CFBundleExecutable differs from the framework name without .framework, which Apple requires to match, resolution still follows CFBundleExecutable, the key macOS uses. The result reports the mismatch as a limitation.
Fail closed, with a typed reason and the probed paths, for each case:
- (a) No Info.plist is present in any supported layout.
- (b) More than one layout's Info.plist is present in a newly admitted bundle type.
- (c) Info.plist is present but has no CFBundleExecutable, as in a codeless bundle. REA does not guess from directory contents.
- (d) The declared program file is absent.
- (e) A framework has Versions/ but no Versions/Current.
- (f) A path escapes the bundle.
- (g) The program file is not an admitted binary format. This keeps the existing file_format_rejected outcome that .app produces for a script.
For (c) and (d), the remediation names the Info.plist path for inspect_plist.
Other directories. Other Apple bundle extensions, such as .dext, .kext, .qlgenerator, and .mdimporter, stay rejected. The message names the directory as an Apple bundle type that this route does not open, lists the accepted bundle types, and suggests selecting the program file. It does not suggest the JavaScript analyzer. A directory without a bundle extension may keep the JavaScript/Electron route, but the message must also list the accepted Apple bundle types.

Acceptance criteria

Fixtures (Xcode 27.0 (27A266a) command-line tools; ./fixture is any scratch directory):

printf 'int demo(void){return 1;}\n' > demo.c
mkdir -p ./fixture/Demo.framework/Versions/A/Resources && cd ./fixture/Demo.framework
clang -dynamiclib -install_name @rpath/Demo.framework/Versions/A/Demo -o Versions/A/Demo ../../demo.c
plutil -create xml1 Versions/A/Resources/Info.plist
plutil -insert CFBundleExecutable -string Demo Versions/A/Resources/Info.plist
plutil -insert CFBundleIdentifier -string com.example.Demo Versions/A/Resources/Info.plist
ln -s A Versions/Current && ln -s Versions/Current/Demo Demo && ln -s Versions/Current/Resources Resources
codesign -s - . && cd ../..
# Ext.appex, Svc.xpc, Plug.bundle, Plug.plugin, Ext.systemextension: Contents/Info.plist + Contents/MacOS/<name>, built with clang -bundle
# Flat.framework: Info.plist and the dylib at the bundle root

rea inspect-macho ./fixture/Demo.framework succeeds, and the subject path ends in Versions/A/Demo. rea inspect-signature on the same directory reports identifier com.example.Demo, and rea inspect-plist reports CFBundleExecutable Demo from Versions/A/Resources/Info.plist with no --relative-path.
The same three commands succeed on the stock MapsDiagnostic.appex, CreateML.framework, and intents_helper.xpc paths quoted above, and each Evidence names the bundle directory, its layout, and its Info.plist.
open_binary over MCP opens ./fixture/Demo.framework and each Contents-layout fixture; inspect_macho, inspect_signature, and inspect_plist then work on the active target.
Flat.framework resolves through the root layout.
After Versions/Current is removed from a copy of Demo.framework, the open fails with a typed reason that names Versions/Current. After it is repointed outside the bundle, the open fails with the containment reason.
With CFBundleExecutable renamed to Other, the open fails because the program file is missing. With it renamed to Other and Versions/A/Other present, the open succeeds with a name-mismatch limitation.
Stock /System/Library/CoreServices/RawCameraSupport.bundle, whose Info.plist has no CFBundleExecutable although Contents/MacOS/ holds a file, fails with a typed missing-key reason, and the open does not select that file. Stock /System/Library/Frameworks/Accelerate.framework, whose Info.plist names Accelerate while no such file exists on disk, fails with a typed missing-program-file reason. Both remediations name the Info.plist path.
A Contents-layout .bundle fixture whose program file is a shell script fails with file_format_rejected, matching .app.
Stock /System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBFTDI.dext is rejected. The message names it as an unsupported Apple bundle type, lists the accepted types, and does not mention analyze_javascript_application.
Existing .app, iOS-style, and Wrapper tests still pass, and the docs list the accepted bundle types (docs/mcp-prompts.md says only "files and macOS app bundles").

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Affected area

Target admission shared by open_binary, the CLI inspection commands, and the doctor target check; bundle program-file resolution; the inspect_plist default path; the user message and remediation for directory rejection; and the target documentation.

Non-goals

Changing Apple application graph projection, bundle roles, or nested-bundle discovery.
Flagging Mach-O code outside documented bundle code locations.
Extending Interface Builder, asset catalog, keyed archive, or dyld load-resolution tools beyond the .app and Mach-O targets they accept today.
Changing signature semantics, codesign invocation, or what inspect_signature reports.
Opening .dext, .kext, .qlgenerator, .mdimporter, .xcframework, or .dSYM directories, or resolving codeless bundles to a program file.
Selecting a non-current framework version. Only Versions/Current is followed.

Verification available so far

I have a prototype or observed results

Verification details (optional)

No response

Alternatives considered

Admit any directory that has a resolvable Info.plist and CFBundleExecutable, regardless of extension. This covers more types, but it would also open arbitrary directories that happen to hold an Info.plist, and it would change what the JavaScript route sees. An explicit extension list fails closed and can grow.
Only fix the message. That removes the misleading advice, but analysts would still resolve each program file and plist by hand.

Possible direction

No response

References

Placing content in a bundle says "apps, app extensions, frameworks, and plug-ins are all bundles". Its table places Info.plist at Contents/Info.plist (macOS), Versions/A/Resources/Info.plist (macOS framework), and Info.plist (iOS, watchOS, tvOS, visionOS). It places the main executable in Contents/MacOS/, Versions/A/, and / respectively. For frameworks, the page says to "Create a symlink within Versions called Current that targets A" and that "The framework's root must contain only the Versions directory and symlinks." It also states that "A codeless bundle has no executable code."
CFBundleExecutable: "For a framework, it's the shared library framework and must have the same name as the framework but without the .framework extension," and "macOS uses this key to locate the bundle's executable or shared library in cases where the user renames the app or bundle directory."
REA already recognizes these extensions as bundles in application graphs (appleBundleAnatomy.ts#L8-L9), and the target docs limit admission to "files and macOS app bundles" (mcp-prompts.md#L33-L35). Resolution fails closed today when CFBundleExecutable is missing (AppBundleExecutable.ts#L257-L263).
Related issues and PRs:
- #720 and PR #733 introduced the JavaScript-route message for JavaScript directories. This request keeps that route and stops applying it to Apple bundles.
- PR #910 added the flat and Wrapper .app layouts. This request extends the same resolution to other bundle types.
- PR #3774 (on main) resolves the inspect_plist default from a Contents/MacOS program file. It does not cover directory targets or frameworks, and main at d52a488 does not change the directory admission or the message.
- #3359 and PR #3505 concern layout detection in the graph projection, not target admission.
- #3289 asks broadly for iOS application support.
- Searches for appex, CFBundleExecutable, directory_requires_file, Versions/Current, systemextension, and bundle directory target found no request for this outcome.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4310 Originally assigned to: @kaoru0822-kitauji on GitHub. ### Before submitting - [X] I searched the open and closed issues and pull requests for a related proposal. - [X] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [X] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation Let `open_binary`, `inspect_macho`, `inspect_signature`, and `inspect_plist` (and their CLI commands) accept `.appex`, `.framework`, `.xpc`, `.systemextension`, `.bundle`, and `.plugin` directories. REA should resolve the program file through the bundle's `Info.plist` `CFBundleExecutable`, the way it resolves `.app` today, and add the macOS framework layout (`Versions/Current/Resources/Info.plist`, program file in `Versions/Current/`). Cases that cannot be resolved should fail closed with a typed reason. The rejection that Apple bundle directories receive today points the analyst to the JavaScript/Electron analyzer, which is misleading. This request replaces that message. An analyst who inspects an app's extension, framework, or XPC service usually has the bundle directory, not the program file inside it. REA admits only one kind of directory: in `resolveAppBundle`, any directory whose extension is not `.app` is rejected with constraint `directory_requires_file` ([BinaryTargetResolver.ts#L435-L451](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/application/BinaryTargetResolver.ts#L435-L451)). Every target opened by `open_binary`, the CLI inspection commands, and the doctor target check passes through this resolver ([BinaryTargetResolver.ts#L92-L97](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/application/BinaryTargetResolver.ts#L92-L97)). The `.app` resolver itself knows only two layouts, `Contents/Info.plist` with `Contents/MacOS/`, and a flat root `Info.plist` ([AppBundleExecutable.ts#L21-L37](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/application/AppBundleExecutable.ts#L21-L37)). It therefore has no route to a macOS framework's `Versions/A/Resources/Info.plist`. The rejection message is fixed text that recommends the JavaScript analyzer for any non-`.app` directory ([analysisErrorPresentation.ts#L266-L268](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/analysisErrorPresentation.ts#L266-L268)). The remediation does the same ([analysisErrorPresentation.ts#L80-L84](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/analysisErrorPresentation.ts#L80-L84)). The CLI commands show the same text, even though the analyst never called `open_binary`. Observed with `npx -y rea-agents@6.5.0` (`--version` prints `6.5.0`, release commit `3b79af28e80785afce9f5998d8f03289402a1847`) on macOS 27.0.1 (26A434) arm64. `rea inspect-macho`, `rea inspect-signature`, and `rea inspect-plist` each exit 1 with the same error for three stock bundles: `/System/Applications/Maps.app/Contents/PlugIns/MapsDiagnostic.appex`, `/System/Library/Frameworks/CreateML.framework`, and `/System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc`: ```text code: target_unavailable category: unavailable message: open_binary accepts files and macOS app bundles. This target is a directory; JavaScript/Electron application directories can be analyzed directly with analyze_javascript_application or `rea analyze <directory>`. remediation: action: "For a JavaScript/Electron application directory, call analyze_javascript_application with input_path or run `rea analyze <directory>`. For binary analysis, select its executable file." details: reason: this opening route requires a file or app bundle constraint: directory_requires_file ``` A self-built, ad-hoc-signed `./fixture/Demo.framework` with the documented `Versions/A` layout fails the same way. `codesign -dv` reports it as `Format=bundle with Mach-O thin (arm64)`, so Apple's own tool treats it as a bundle. When the framework's program file `Versions/A/Demo` is given to `rea inspect-plist` instead, the command looks for `Versions/A/Contents/Info.plist` and fails with `capability_unavailable`, because the default plist is `Contents/Info.plist` beside the program directory ([NativeMacOSProvider.ts#L1153-L1166](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/NativeMacOSProvider.ts#L1153-L1166)). The analyst must locate the program file and the plist by hand, and the resulting Evidence names a loose file rather than the bundle it came from. ### Use cases _No response_ ### Desired outcome and success criteria - **Admission.** A directory whose extension is `.appex`, `.framework`, `.xpc`, `.systemextension`, `.bundle`, or `.plugin` (case-insensitive) is opened like `.app`. Behavior for `.app`, including the iOS-on-Mac `Wrapper` layout, is unchanged. - **Layouts.** Resolution reads `CFBundleExecutable` from the bundle's `Info.plist` in the macOS `Contents/` layout and the flat iOS-style root layout that REA already supports. For `.framework`, it also reads the macOS versioned layout: `Info.plist` at `Versions/Current/Resources/Info.plist`, program file `Versions/Current/<CFBundleExecutable>`. All symlinks, including `Versions/Current` and the root symlinks, must resolve inside the bundle, under the same containment rule `.app` uses. The flat root layout covers iOS-style frameworks and extensions. - **Evidence.** The subject remains the resolved program file, with its digest as today. The result records the bundle directory, the bundle type, the layout used, the `Info.plist` path, and, for a versioned framework, the version directory that `Versions/Current` selects. The default `inspect_plist` target is that `Info.plist`, and `inspect_plist` relative paths resolve from the bundle root. - **Framework name.** When a framework's `CFBundleExecutable` differs from the framework name without `.framework`, which Apple requires to match, resolution still follows `CFBundleExecutable`, the key macOS uses. The result reports the mismatch as a limitation. - **Fail closed, with a typed reason and the probed paths, for each case:** - (a) No `Info.plist` is present in any supported layout. - (b) More than one layout's `Info.plist` is present in a newly admitted bundle type. - (c) `Info.plist` is present but has no `CFBundleExecutable`, as in a codeless bundle. REA does not guess from directory contents. - (d) The declared program file is absent. - (e) A framework has `Versions/` but no `Versions/Current`. - (f) A path escapes the bundle. - (g) The program file is not an admitted binary format. This keeps the existing `file_format_rejected` outcome that `.app` produces for a script. For (c) and (d), the remediation names the `Info.plist` path for `inspect_plist`. - **Other directories.** Other Apple bundle extensions, such as `.dext`, `.kext`, `.qlgenerator`, and `.mdimporter`, stay rejected. The message names the directory as an Apple bundle type that this route does not open, lists the accepted bundle types, and suggests selecting the program file. It does not suggest the JavaScript analyzer. A directory without a bundle extension may keep the JavaScript/Electron route, but the message must also list the accepted Apple bundle types. **Acceptance criteria** Fixtures (Xcode 27.0 (27A266a) command-line tools; `./fixture` is any scratch directory): ```sh printf 'int demo(void){return 1;}\n' > demo.c mkdir -p ./fixture/Demo.framework/Versions/A/Resources && cd ./fixture/Demo.framework clang -dynamiclib -install_name @rpath/Demo.framework/Versions/A/Demo -o Versions/A/Demo ../../demo.c plutil -create xml1 Versions/A/Resources/Info.plist plutil -insert CFBundleExecutable -string Demo Versions/A/Resources/Info.plist plutil -insert CFBundleIdentifier -string com.example.Demo Versions/A/Resources/Info.plist ln -s A Versions/Current && ln -s Versions/Current/Demo Demo && ln -s Versions/Current/Resources Resources codesign -s - . && cd ../.. # Ext.appex, Svc.xpc, Plug.bundle, Plug.plugin, Ext.systemextension: Contents/Info.plist + Contents/MacOS/<name>, built with clang -bundle # Flat.framework: Info.plist and the dylib at the bundle root ``` - [ ] `rea inspect-macho ./fixture/Demo.framework` succeeds, and the subject path ends in `Versions/A/Demo`. `rea inspect-signature` on the same directory reports identifier `com.example.Demo`, and `rea inspect-plist` reports `CFBundleExecutable` `Demo` from `Versions/A/Resources/Info.plist` with no `--relative-path`. - [ ] The same three commands succeed on the stock `MapsDiagnostic.appex`, `CreateML.framework`, and `intents_helper.xpc` paths quoted above, and each Evidence names the bundle directory, its layout, and its `Info.plist`. - [ ] `open_binary` over MCP opens `./fixture/Demo.framework` and each Contents-layout fixture; `inspect_macho`, `inspect_signature`, and `inspect_plist` then work on the active target. - [ ] `Flat.framework` resolves through the root layout. - [ ] After `Versions/Current` is removed from a copy of `Demo.framework`, the open fails with a typed reason that names `Versions/Current`. After it is repointed outside the bundle, the open fails with the containment reason. - [ ] With `CFBundleExecutable` renamed to `Other`, the open fails because the program file is missing. With it renamed to `Other` and `Versions/A/Other` present, the open succeeds with a name-mismatch limitation. - [ ] Stock `/System/Library/CoreServices/RawCameraSupport.bundle`, whose `Info.plist` has no `CFBundleExecutable` although `Contents/MacOS/` holds a file, fails with a typed missing-key reason, and the open does not select that file. Stock `/System/Library/Frameworks/Accelerate.framework`, whose `Info.plist` names `Accelerate` while no such file exists on disk, fails with a typed missing-program-file reason. Both remediations name the `Info.plist` path. - [ ] A Contents-layout `.bundle` fixture whose program file is a shell script fails with `file_format_rejected`, matching `.app`. - [ ] Stock `/System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBFTDI.dext` is rejected. The message names it as an unsupported Apple bundle type, lists the accepted types, and does not mention `analyze_javascript_application`. - [ ] Existing `.app`, iOS-style, and `Wrapper` tests still pass, and the docs list the accepted bundle types (`docs/mcp-prompts.md` says only "files and macOS app bundles"). ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) **Affected area** Target admission shared by `open_binary`, the CLI inspection commands, and the doctor target check; bundle program-file resolution; the `inspect_plist` default path; the user message and remediation for directory rejection; and the target documentation. **Non-goals** - Changing Apple application graph projection, bundle roles, or nested-bundle discovery. - Flagging Mach-O code outside documented bundle code locations. - Extending Interface Builder, asset catalog, keyed archive, or dyld load-resolution tools beyond the `.app` and Mach-O targets they accept today. - Changing signature semantics, codesign invocation, or what `inspect_signature` reports. - Opening `.dext`, `.kext`, `.qlgenerator`, `.mdimporter`, `.xcframework`, or `.dSYM` directories, or resolving codeless bundles to a program file. - Selecting a non-current framework version. Only `Versions/Current` is followed. ### Verification available so far I have a prototype or observed results ### Verification details (optional) _No response_ ### Alternatives considered - Admit any directory that has a resolvable `Info.plist` and `CFBundleExecutable`, regardless of extension. This covers more types, but it would also open arbitrary directories that happen to hold an `Info.plist`, and it would change what the JavaScript route sees. An explicit extension list fails closed and can grow. - Only fix the message. That removes the misleading advice, but analysts would still resolve each program file and plist by hand. ### Possible direction _No response_ ### References - [Placing content in a bundle](https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle) says "apps, app extensions, frameworks, and plug-ins are all bundles". Its table places `Info.plist` at `Contents/Info.plist` (macOS), `Versions/A/Resources/Info.plist` (macOS framework), and `Info.plist` (iOS, watchOS, tvOS, visionOS). It places the main executable in `Contents/MacOS/`, `Versions/A/`, and `/` respectively. For frameworks, the page says to "Create a symlink within `Versions` called `Current` that targets `A`" and that "The framework's root must contain only the `Versions` directory and symlinks." It also states that "A codeless bundle has no executable code." - [CFBundleExecutable](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleexecutable): "For a framework, it's the shared library framework and must have the same name as the framework but without the `.framework` extension," and "macOS uses this key to locate the bundle's executable or shared library in cases where the user renames the app or bundle directory." - REA already recognizes these extensions as bundles in application graphs ([appleBundleAnatomy.ts#L8-L9](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/apple/appleBundleAnatomy.ts#L8-L9)), and the target docs limit admission to "files and macOS app bundles" ([mcp-prompts.md#L33-L35](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/docs/mcp-prompts.md#L33-L35)). Resolution fails closed today when `CFBundleExecutable` is missing ([AppBundleExecutable.ts#L257-L263](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/application/AppBundleExecutable.ts#L257-L263)). - Related issues and PRs: - #720 and PR #733 introduced the JavaScript-route message for JavaScript directories. This request keeps that route and stops applying it to Apple bundles. - PR #910 added the flat and `Wrapper` `.app` layouts. This request extends the same resolution to other bundle types. - PR #3774 (on `main`) resolves the `inspect_plist` default from a `Contents/MacOS` program file. It does not cover directory targets or frameworks, and main at `d52a488` does not change the directory admission or the message. - #3359 and PR #3505 concern layout detection in the graph projection, not target admission. - #3289 asks broadly for iOS application support. - Searches for `appex`, `CFBundleExecutable`, `directory_requires_file`, `Versions/Current`, `systemextension`, and `bundle directory target` found no request for this outcome.

bsakaguchi commented

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

Author

Owner

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

I opened #8117. It implements the admission, the three layouts, fail-closed cases (a)–(g), and the rejection messages. I checked it on the stock bundles quoted here and on your clang-built fixture set (inspect-macho, inspect-signature and inspect-plist succeed on all seven fixtures).

Two items are deliberately left for follow-up, so this issue stays open:

Bundle directory, type, layout and version in inspect_macho and inspect_signature Evidence. The subject is the strict schema shared by all Evidence. inspect_plist already reports resource_root with the bundle directory, layout and Info.plist.
The framework name-mismatch limitation. Resolution follows CFBundleExecutable, but executable targets have no limitation channel to carry the note.

@kaoru0822-kitauji commented on GitHub (Oct 30, 2026): I opened #8117. It implements the admission, the three layouts, fail-closed cases (a)–(g), and the rejection messages. I checked it on the stock bundles quoted here and on your clang-built fixture set (`inspect-macho`, `inspect-signature` and `inspect-plist` succeed on all seven fixtures). Two items are deliberately left for follow-up, so this issue stays open: 1. Bundle directory, type, layout and version in `inspect_macho` and `inspect_signature` Evidence. The subject is the strict schema shared by all Evidence. `inspect_plist` already reports `resource_root` with the bundle directory, layout and Info.plist. 2. The framework name-mismatch limitation. Resolution follows `CFBundleExecutable`, but executable targets have no limitation channel to carry the note.

bsakaguchi referenced this issue

2026-10-31 00:54:53 +00:00

[PR #1714] [MERGED] docs(website): highlight the setup guide on the homepage #4771

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

No description provided.

Rows
Columns