computer-use: request_access can't resolve an installed/running app (Bartender 6) that its own click-gate names as the blocker

Summary

Two distinct bugs surfaced while using the computer-use MCP tool against a normal, real-world Mac (one with Bartender 6, a popular menu-bar manager, installed and running):

1. request_access cannot resolve an app that is verifiably installed and running under the exact name it was asked about. Requesting access to "Bartender 6" returned "doesn't match any installed or running application", even though /Applications/Bartender 6.app is installed, its display name is literally "Bartender 6" (verified via mdls), and its process was running the whole time (verified via ps). This leaves no way to grant an app the click-gate has already identified as blocking a click — a dead end with no documented recovery path.
2. The click-gate's screen-region ownership check attributed a click well inside another app's window content — not the system menu bar — to Bartender 6. Bartender's real, expected behavior is intercepting the system menu bar strip, so a block there is plausible and arguably correct. But a later click at [511, 53], inside Tolaria's own toolbar (nowhere near the menu bar), was also attributed to Bartender 6 — which has no plausible architectural explanation and looks like a genuine misattribution.

A third, separate anomaly was also observed and is included for completeness: a dialog button click reported success ("Clicked.", no error) with no visible effect, twice in a row, only resolved by sending Return via the keyboard instead.

This is not a Bartender bug report — Bartender doing intrusive things to the system menu bar is its documented purpose. Everything here is about Claude Code's computer-use tool: its app-name resolver, and (for bug 2) its region-to-owner attribution.

Environment

• macOS (Darwin 25.6.0), Claude Code CLI session
• Target app: Tolaria.app (bundle id club.refactoring.tolaria), granted at "full" tier via request_access
• Bartender 6.6.2 (com.surteesstudios.Bartender), installed at /Applications/Bartender 6.app, running continuously throughout the session (PID 950, multi-hour uptime, active CPU use)
• Wispr Flow (com.electron.wispr-flow) also installed/running

Steps to reproduce

1. request_access(apps: ["Tolaria"]) → granted, tier "full".
2. open_application("Tolaria") → Tolaria becomes frontmost.
3. screenshot() → confirms Tolaria's own menu bar ("File", "Edit", "View", "Note", "Vault", "Window") rendered at the top of the screen, y≈14.
4. left_click([115, 14]) (the "File" menu text) →

``
Error: Click at these coordinates would land on "Bartender 6", which is not in the allowed applications.
``

1. Retried at [322, 14] ("Vault" menu) → same error, same claimed owner.
2. Attempted to resolve by granting the blamed app:

``
request_access(apps: ["Bartender 6"], reason: "...")
→ {"granted":[],"denied":[],
"notInstalled":{"apps":[{"requestedName":"Bartender 6","didYouMean":[]}],
"guidance":"\"Bartender 6\" doesn't match any installed or running application.
The request was NOT shown to the user. ..."}}
`
Independently verified this was wrong:
`
$ find /Applications -iname "*bartender*" -maxdepth 2
/Applications/Bartender 5.app
/Applications/Bartender 6.app
$ ps aux | grep -i bartender
artcashin 950 16.5 0.2 ... /Applications/Bartender 6.app/Contents/MacOS/Bartender 6
$ mdls -name kMDItemDisplayName "/Applications/Bartender 6.app"
kMDItemDisplayName = "Bartender 6"
`
The exact string the click-gate blamed, and the exact string passed to request_access`, matches the app's real, installed, running display name character-for-character.

1. Worked around step 4–6 by driving the same action through an in-app UI element instead of the system menu bar (Tolaria's own vault-switcher popover, opened by clicking its status-bar label) — this click succeeded normally, confirming clicks on Tolaria's own window generally work fine.
2. Later, from that popover, clicked "Open local folder," which opened a native macOS NSOpenPanel. A click inside that dialog's file list, at [529, 350], was blocked:

``
Error: Click at these coordinates would land on "Wispr Flow", which is not in the allowed applications.
`
request_access(["Wispr Flow"]) *did* resolve this one (com.electron.wispr-flow, tier "full"`), and granting it allowed the click to proceed.

1. After selecting the target folder inside that same dialog, clicked its "Open" button at [1031, 607] twice — both times returned "Clicked." with no error, but the dialog remained open and unchanged. Pressing Return on the keyboard was what actually confirmed the dialog.

Expected behavior

• request_access should resolve an app whose bundle is installed and whose process is running under exactly the requested display name.
• A screen region's attributed "owner" should correspond to a window actually rendering visible, interactive content there — not to a background/menu-bar-only app with no plausible presence at that location (e.g., deep inside another app's toolbar).
• A reported "Clicked." result should correspond to an actual state change; a click with zero effect should be distinguishable from one that worked.

Actual behavior

• request_access(["Bartender 6"]) falsely reported the app as not installed/running, despite it being demonstrably present — the click-gate and the resolver disagree about the same app's existence.
• The click-gate attributed a click inside Tolaria's own toolbar (not the menu bar) to Bartender 6, which has no architectural basis given Bartender's known scope (menu bar interception only).
• A dialog button click silently no-op'd while reporting success.

Impact

A task that should have been a handful of tool calls (open a menu or dialog, click a folder, confirm) took roughly a dozen extra calls, one dead-end request_access grant that couldn't be resolved despite the app being real, one workaround by switching to an in-app control to route around the system menu bar entirely, and a fallback to keyboard input to get past the silent button no-op. Bartender is a very common utility (menu-bar management apps as a category — Bartender, Vanilla, Dozer, iStat Menus — are widely installed), so bug 1 alone (a real, running, correctly-named app that request_access can't find) will recur for any user running one, with no documented way out once hit.

Suggested areas to investigate

• Why request_access's installed/running-app resolver and the click-gate's region-ownership check can disagree about whether the same, exactly-named app exists — they appear to consult different app inventories.
• Whether the resolver's app inventory excludes apps running as background/menu-bar-only processes (no normal foreground window), which would explain a menu-bar utility specifically failing to resolve even though a Dock-style foreground app (Wispr Flow's Electron process, in this case) resolved fine.
• Whether the click-gate's "region belongs to app X" lookup has a caching or bounding-box bug that let a menu-bar-scoped app's ownership leak into an unrelated in-window coordinate later in the same session.
• Whether button clicks that produce no window/state change can be detected and surfaced rather than reported as a bare success.

Suggested workaround to document (until fixed)

If a click is blocked citing an app that request_access then reports as "not installed": don't retry the same coordinate. Prefer routing the same action through the target app's own in-window UI (menus, buttons, popovers) instead of the system menu bar, and fall back to keyboard navigation (Tab/Return/Escape) when an in-window click is blocked with no resolvable owner.