[BUG] computer-use: request_access filters out apps with LSUIElement=YES, blocking menubar-only apps

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

request_access returns notInstalled for macOS apps that set LSUIElement = YES in their Info.plist. These are menubar-only apps — legitimate GUI applications with windows, panels, and user interaction. They simply suppress the Dock icon and app-switcher entry.

The native listInstalledApps() implementation appears to check each app's LSUIElement Info.plist key and exclude apps where it is truthy. This causes the app to be completely absent from the installed apps list, so name resolution never matches it.

The filter is too aggressive. LSUIElement apps are full GUI apps — not background daemons. Filtering LSBackgroundOnly makes sense (those truly have no GUI), but LSUIElement should be treated like any other app.

Proof that LSUIElement is the specific cause:

Testing with multiple menubar-only apps on the same machine:

| App | LSUIElement in Info.plist | request_access result |
|-----|:-----------:|:--------------:|
| App A | YES / 1 | notInstalled |
| App B | 0 (explicitly false) | granted |
| App C | not set | granted |
| App D | not set | granted |

All four apps are menubar-only with no Dock icon. The only difference is the Info.plist LSUIElement value. Apps B, C, and D achieve their menubar-only behavior through other means (e.g., NSApplication.setActivationPolicy(.accessory) at runtime).

Standard macOS APIs all find the affected app without issue:

• NSWorkspace.shared.runningApplications — finds it
• NSWorkspace.shared.urlForApplication(withBundleIdentifier:) — finds it
• LSCopyApplicationURLsForBundleIdentifier — finds it
• Spotlight mdfind "kMDItemContentType == 'com.apple.application-bundle'" — finds it

Additionally, the screenshot filtering system knows the app is running — it hides the app's windows from screenshots because it's not in the allowlist. This contradicts request_access claiming the app is not installed.

What Should Happen?

Apps with LSUIElement = YES should not be filtered from listInstalledApps(). They should be available for request_access like any other GUI app.

Many popular macOS apps use LSUIElement: Bartender, Raycast, and many developer menubar tools.

Suggested Fix

Remove the LSUIElement check from the app filtering logic in the native module, keeping only the LSBackgroundOnly check. Apps that set LSUIElement but happen to have no visible windows at a given moment will simply not appear in screenshots anyway, so there's no harm including them in the installed apps list.

Steps to Reproduce

1. Install any macOS app that has LSUIElement = YES in its Info.plist to /Applications/
2. Launch the app (it will appear in the menubar, not the Dock)
3. Enable computer-use MCP via /mcp
4. Call request_access with the app's display name or bundle ID
5. Result: notInstalled — the request is never shown to the user
6. Take a screenshot — output message lists the app among hidden apps, proving the system knows it's running

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Latest (Claude Desktop)

Platform

Anthropic Console (claude.ai)

Operating System

macOS

Terminal/Shell

zsh

Additional Information

Related: #43091 (Apple Notes not found) may share the same underlying filtering issue.