computer-use · git:20261015.0567d17 · 2026-10-15 · sha256 6c561ee65a07599d
computer-use git:20261015.0567d17A
Immutable. This exact content never changes and is served at /api/v1/blob/6c561ee65a07599d.
--- name: computer-use description: >- Operate and test graphical applications through screenshots, coordinates, and input events using available shell tools or platform automation. Use for desktop GUI interaction, game reproductions, and scripted visual workflows, including private headless desktops. --- # Computer use A vision-capable agent needs an action/capture tool and a way to read images. Shell commands plus an image-capable file reader satisfy this contract. Use the available automation backend; do not make a dedicated MCP or wrapper a prerequisite. Prefer an existing CLI or API when the task does not require exercising the GUI. ## Establish the session Before execution tests, apply `$e2e-side-effect-safety` if available. Establish ownership and effective routing before launching or sending input. Continue autonomously when the session is verified private and non-disturbing; otherwise inspect or isolate it, and ask before unavoidable interaction with a shared desktop. For local tests, own the desktop, application instance, config/profile, writable data, screenshots, and process lifecycle. A separate display alone does not isolate saves, audio, credentials, network traffic, or single-instance application IPC. Use private fixtures and verify application-specific paths and fallbacks. Silence the test application's output without changing the user's audio. For offline tests, verify that the app cannot contact external services; headless is not offline. Bound runtime and resource use so the private test does not monopolize the host. Choose tools against the actual session: - X11: read [the Xvfb/Openbox reference](references/x11.md) for a private desktop, screenshot capture, and `xdotool` events. - Wayland: use a private compositor/session and its supported capture/input tools. Verify that both address that session; global input injection can reach the user's real seat. X11 tools only cover applicable Xwayland clients, not every native app. - Other platforms: use their available automation tools with a verified private session, VM, simulator, or explicitly authorized device. Preserve the same loop. Record the session identifier, owned process identities, application/window, capture dimensions, input coordinate space, and scratch directory. Recheck these after a restart or routing change. Do not silently fall back to the user's desktop. ## Observe, act, observe 1. Capture a fresh screenshot from the target session and actually read the image. Confirm the expected application, state, geometry, and focus. 2. Identify the target in that image. Map displayed image coordinates to the input tool's coordinate space, accounting for resizing, crop offsets, window borders, and display scaling. Keep this transform explicit. 3. Send the intended click, drag, scroll, text, or key events. Pair held keys and buttons with releases, including error/cancellation cleanup. Use actual input events when input behavior is what the test measures. 4. Wait for the application to process the action, then capture and inspect the result. Prefer bounded state/readiness checks where available; a command exit code or fixed sleep alone does not prove the intended transition occurred. Reobserve after unexpected dialogs, navigation, geometry changes, focus loss, or failed expectations. Do not keep clicking old coordinates to recover blindly. Logs and application instrumentation can establish mechanics or hidden state; visual claims require rendered evidence. Verify whether capture includes the pointer before using a screenshot to judge cursor visibility. ## Batch established interactions Once observation has established a stable layout and event sequence, script the sequence without requiring model observation between every action. Keep its preconditions, waits, timeout, and expected end state explicit. Add checkpoints at uncertain transitions; stop and return evidence when a checkpoint fails. Coordinate stability must be reestablished after resizing, scrolling, layout changes, or restarts. For repeated runs, record each iteration's completion and outcome; a final screenshot alone does not establish how many repetitions succeeded. For fewer model round trips, one orchestration call can sequentially perform `actions -> wait -> screenshot -> image read -> return image`. If the harness cannot return images from that call, use a separate image read; this adds overhead but does not block computer use. Printing a PNG path or base64 as text does not give the model an image. Keep dependent steps ordered; parallel capture may precede the action. Parallelize only independent work with independently owned resources. Crop to the region in question and stack related frames, such as before and after, into one image so a single read covers them. To detect a change or wait for a transition, compare pixels in the script and read an image only when it matters. ## Finish Verify the requested outcome from the final observed state and relevant evidence. Report what was actually exercised and any remaining verification gap. Keep useful reproduction scripts and evidence at known paths. Release held input, close the owned application, and stop the owned desktop when finished unless continued use is requested. Identify processes before cleanup; never kill by broad application name or reset shared services.