[BUG] Computer Use: request_access returns notInstalled for a locally-built app despite valid, correct Spotlight/LaunchServices metadata (distinct from #43759/#43757/#43760)

What's Wrong?

The computer-use MCP's request_access tool consistently returns notInstalled for
a custom, locally-built macOS app, across every variable I could think to test —
including several I could directly verify were not the cause via before/after
measurement. A different local third-party app (never previously granted access)
resolved correctly on the very first attempt under otherwise-similar conditions.

This looks related to #43759 / #43757 / #43760 (all closed in a circular
"duplicate of each other" loop, never triaged by a maintainer), but the specific
mechanism those reports hypothesize (mdls -name kMDItemCFBundleIdentifier
returning (null)) does not reproduce here — my Spotlight metadata is fully
populated and correct for every app tested, including the one that fails.

Environment

• macOS 26.5.1 (Build 25F80)
• Apple Silicon (arm64)
• Claude Desktop app (macOS)

Steps to Reproduce

1. Build a local macOS app bundle (swiftc-compiled, .app bundle), signed with

an Apple Development certificate (not Developer ID / not notarized).
LSUIElement=true (menu-bar-only, no Dock icon).

1. Install to /Applications/.
2. Call request_access(["<AppDisplayName>"]) (also tried: .app-suffixed name,

bundle identifier, and the unspaced CFBundleExecutable process name — all
four fail identically).

1. Observe: notInstalled, with didYouMean suggestions that are unrelated apps,

and guidance text stating the request was never shown to the user.

What I Ruled Out (each verified with direct measurement, not just retried)

1. Static LSUIElement key — edited the real installed app's Info.plist to

LSUIElement=false, re-signed (required after editing Info.plist), relaunched.
Verified via lsappinfo list that the running process genuinely reported
type="Foreground" (not UIElement). request_access result unchanged.
Reverted afterward (confirmed back to UIElement).

1. Runtime activation policy, independent of the plist — added a real,

in-app NSApp.setActivationPolicy(.regular) toggle (persisted via
UserDefaults), verified via lsappinfo (type="Foreground") and a
screenshot showing an actual (generic-icon) Dock tile. request_access
result unchanged.

1. Full app relaunch after each change above — no change.

1. Full Claude Desktop quit + relaunch, new session — identical result,

byte-for-byte same didYouMean suggestions and guidance text.

1. LaunchServices registration — ran

lsregister -f "/Applications/<App>.app", then confirmed via
lsregister -dump | grep -i <app> that the app is correctly registered:
correct bundle id, correct path, real teamID, and a trustedCodeSignatures
hash present. request_access unchanged immediately after.

1. Spotlight indexing — mdfind "kMDItemCFBundleIdentifier == '<bundle.id>'"

correctly returns the app's path(s). Also, unlike #43759's reported symptom,
mdls -name kMDItemCFBundleIdentifier "/Applications/<App>.app" returns the
correct, non-null bundle identifier — for both the failing app and every
other app tested (see table below). So the specific failure mode described in
#43759 does not apply to this case.

1. Gatekeeper/notarization status — spctl -a -vv on the failing app returns

rejected / origin=Apple Development: ... (expected — Development certs are
never notarized). This looked like a plausible differentiator until tested
against a counterexample: a completely unrelated, already-installed
third-party app that is also Gatekeeper-rejected (origin=Mac Developer:
...) resolved via request_access successfully on the very first try — real
permission dialog shown, approved, granted response with a real bundleId
and tier. So two different Gatekeeper-rejected apps produced two different
outcomes; this rules out signing/notarization trust as the differentiator.

mdls comparison (all correct, none null — see point 6 above)

| App | kMDItemCFBundleIdentifier | request_access result |
|---|---|---|
| Failing local app | correct, non-null | notInstalled (every attempt) |
| Working 3rd-party app (never granted before) | correct, non-null | granted (first try) |
| Discord (for reference) | correct, non-null | not tested |
| Notes (system app, for reference) | correct, non-null | not tested |

The One Unexplained Asymmetry

• Working app: an existing, previously-installed, real third-party

application (had never been granted computer-use access before this session,
but has presumably existed on the machine and been used normally for some
time).

• Failing app: a custom app built and installed to /Applications for the

first time within the same debugging session.

The leading remaining (untested) hypothesis is that app-recognition is keyed off
something app-usage-history-related (e.g. a Spotlight "use count"/"last used"
style signal, or a separate OS usage-tracking store) rather than any live,
inspectable property of the bundle itself — since every property we could
directly change or measure (signing, plist keys, runtime policy, LaunchServices
registration, Spotlight indexing) had zero effect.

What Would Help

• Confirmation of what request_access's app-matching actually keys off on

macOS, since it's evidently not simply mdls/kMDItemCFBundleIdentifier
presence (unlike #43759's reported symptom, ours is present and correct), not
Gatekeeper/notarization status (ruled out via counterexample), and not a
snapshot cached at Claude Desktop launch (survived a full quit+relaunch).

• Whether there's an intentional design reason newly-installed/never-before-used

apps are excluded, and if so, whether there's a supported way to make a
freshly-built local app immediately recognizable for legitimate UI-testing
purposes during development (this was the original motivating use case — testing
a locally-developed macOS menu-bar app's UI without a separate raw
AppleScript/cliclick-based automation toolkit).

Happy to provide the full local app bundle details, exact commands run, and raw
output for anything above if useful for reproducing.