Skip to content

fix(computer): a picked app whose process name Linux cut short is not refused - #849

Open
OAraLabs wants to merge 1 commit into
mainfrom
fix/computer-identity-window-app-name
Open

OAraLabs wants to merge 1 commit into
mainfrom
fix/computer-identity-window-app-name

Conversation

@OAraLabs

Copy link
Copy Markdown
Owner

Why

Linux keeps a process name to 15 characters, so cua-driver's list_apps named GNOME Terminal gnome-terminal- (its server process) while its window named the app Gnome-terminal. The pick recorded only the first, and check 1b refused every task in the app the person had picked.

What

AppIdentity.of() takes the resolved window and adds its app name, only when the window is the same process AND the app's name is a cut process name (15 characters) that the window's name completes. Any other name a window gives adds nothing: a pick has no pid, so a wider name would let it cover a different app. The existing "another app is refused" test still holds and has a twin for this rule.

Verification

4 new tests in tests/test_computer_app_identity.py (red before). Computer-use suites 635 passed; ruff clean. On the rig: a Terminal menu item prompted, was denied, then approved and ran.

Not fixed here: two processes with the same cut name (gnome-terminal-server and gnome-terminal-preferences) make the door ask "which one?" with two identical options.

🤖 Generated with Claude Code

… refused

Linux keeps a process name to 15 characters, so cua-driver's list_apps named
GNOME Terminal "gnome-terminal-" (its server process) while its window named
the app "Gnome-terminal". The pick recorded only the first, and check 1b
refused every task in the app the person picked.

AppIdentity.of() now takes the resolved window and adds its app name, but
only when the window is the same process AND the app's name is a cut
process name (15 characters) that the window's name completes. Any other
name a window gives adds nothing: a pick has no pid, so a wider name would
let it cover a different app (the existing Firefox refusal still holds).

Found on the isolated computer-use rig.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant