fix(computer_use): correct type_text MCP tool name and implement drag action#24181
Closed
liuhao1024 wants to merge 1 commit into
Closed
fix(computer_use): correct type_text MCP tool name and implement drag action#24181liuhao1024 wants to merge 1 commit into
liuhao1024 wants to merge 1 commit into
Conversation
… action Bug 3: The cua_backend type_text() method called MCP tool 'type_text_chars' which does not exist in current cua-driver. Changed to 'type_text' which is the correct MCP tool name. Bug 4: The drag() method returned a hardcoded 'not supported' error even though cua-driver exposes a 'drag' MCP tool. Implemented proper drag dispatching with coordinate-based and element-based targeting. Added dispatch-level validation for drag to ensure from/to coordinates or elements are provided before calling any backend. Fixes NousResearch#24170 (bugs 3 and 4)
19 tasks
19 tasks
briandevans
added a commit
to briandevans/hermes-agent
that referenced
this pull request
May 19, 2026
…using frontmost (NousResearch#24170 bug 1) `CuaDriverBackend.capture(app=X)` and `focus_app(app=X)` silently fell back to the frontmost on-screen window when X matched no app — typically a menu-bar utility (e.g. "Fuwari" in the bug reporter's case) rather than the requested app. The agent then received UI elements for the wrong app and clicked / typed into it. The root cause is a localized macOS app name mismatch: `list_windows` returns the localized `app_name` (e.g. "計算機" on a Japanese/Chinese system) but callers naturally pass the English name ("Calculator"). The substring filter doesn't match, and the code falls through to picking the frontmost window with no signal that the filter was effectively dropped. Fix: - `capture(app=…)`: when the filter matches nothing, return a `CaptureResult` with empty `app`/`elements` and a diagnostic `window_title` pointing the caller at `list_apps` and noting the localized-name convention. `_active_pid` / `_active_window_id` are left untouched so a subsequent action doesn't inadvertently hit the wrong process. - `focus_app(app=…)`: when the filter matches nothing, set `target = None` and let the existing `return ActionResult(ok=False, …, "No on-screen window found for app …")` path fire instead of falsely reporting success on the frontmost window. This addresses bug 1 only from NousResearch#24170. Bugs 2 & 5 are addressed in NousResearch#24242, bugs 3 & 4 in NousResearch#24181. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two of the five bugs reported in #24170 for the
computer_usetoolset wrapper layer:Bug 3:
typeaction fails with "Unknown tool: type_text_chars" — Thecua_backend.type_text()method called MCP tooltype_text_charswhich does not exist in current cua-driver. Changed totype_text, the correct MCP tool name.Bug 4:
dragaction returns "not supported" error — Thedrag()method inCuaDriverBackendreturned a hardcoded error even though cua-driver exposes adragMCP tool. Implemented proper drag dispatching with both coordinate-based and element-based targeting, following the same pattern asclick()andscroll().Additionally added dispatch-level validation in
tool.pyto ensuredragreceives either coordinates or element indices before calling any backend, providing a consistent error message across all backend implementations.Changes
tools/computer_use/cua_backend.pytype_text()MCP tool name; implementdrag()tools/computer_use/tool.pydragactiontests/tools/test_computer_use.pyTesting
tests/tools/test_computer_use.pypasstype_text, drag routes with coordinates, drag routes with elements, drag without targets returns errorRemaining bugs from #24170
Bugs 1 (
app=ignored on initial capture), 2 (capture_after=Trueloses app context), and 5 (element labels stripped) involve state management in the capture/app-targeting flow and are not addressed in this PR.Fixes #24170 (bugs 3 and 4)