Computer Use's per-app request_access model pushes users toward a strictly more dangerous standing-permission alternative when it fails to recognize an app

Title

Computer Use's per-app request_access model pushes users toward a strictly more dangerous standing-permission alternative when it fails to recognize an app

Context

This is a design observation distinct from #74619 (a separate app-recognition
bug I filed against request_access from the same investigation), not a
security exploit report. Flagging it because it's a direct, concrete
consequence of #74619, not a theoretical concern.

The observation

request_access's intended model is fine-grained and repeatable: consent
is scoped to a specific application, and (as far as I can tell) has to be
granted again for each new app/session rather than accumulating into a
standing blanket grant.

When request_access fails to recognize a valid, locally-built app (the
#74619 bug), the practical fallback — and the one I actually used, under
my own explicit authorization for this one project — is standard macOS
automation tooling: cliclick, AppleScript via osascript/System Events,
screencapture. Using these requires granting the calling process (in my
case, effectively the terminal/agent host) Accessibility (and/or
Automation) permission once, via a single system dialog under System
Settings > Privacy & Security.

That one-time grant is categorically more dangerous than the model
request_access is trying to implement, not merely "equally ungated":

• It is not scoped to one app — once granted, it authorizes reading the

accessibility tree of, and synthesizing input into, any application on
the system, indefinitely.

• It is not re-requested per session or per target — there's no further

consent dialog the next time it's used against a different app, or in
a new agent session. The grant just sits there, standing, until the
user manually revokes it.

• It generalizes far beyond whatever one project prompted granting it —

once Accessibility access exists for a given process, any future agent
session using that same process inherits it silently.

So the actual comparison isn't "gated tool vs. ungated tool" — it's
"a broken fine-grained per-use gate vs. a working, but much broader and
persistent, standing grant." When the fine-grained tool doesn't work,
users aren't left without automation; they're pushed toward the
coarser, riskier alternative that actually works, defeating the purpose of
having built the fine-grained one in the first place.

Why this seems worth flagging

If #74619's app-recognition bug is common (I have no data on how common,
just my own reproduction), then in practice request_access's broken
recognition may be quietly training users/agents toward reaching for
standing Accessibility-level automation as the reliable fallback whenever
Computer Use fails to recognize a target — which is a strictly worse
security posture than either "Computer Use works and is used" or "Computer
Use fails and no automation happens at all." Fixing #74619 removes the
incentive to reach for the broader, standing-grant fallback in the first
place.

Related

• #74619 — the request_access app-recognition bug that made this

fallback necessary in my case (separate mechanism, not the same root
cause, but this issue exists downstream of it).

Happy to share the exact commands/tooling I used if that's useful context.