On October 30, 2026, Google declared that the Gemini API Computer Use tool had reached general availability (GA) in both the Interactions and GenerateContent APIs. It lets developers build agents that analyze screenshots and propose interface operations such as clicking, typing, and navigating. The AI does not, however, receive unrestricted access to a computer: the developer application executes the actions and must honor any blocks or confirmation requests.
That distinction matters: general availability in two APIs does not mean every Gemini app can automatically control a computer, that every model is compatible, or that risky actions are preapproved. These findings come from documentation; DTech did not conduct a hands-on API test.
What became available on October 30, 2026?
Google’s release notes explicitly record Computer Use moving to GA in the Interactions API and GenerateContent API. GA describes the tool’s release status in these channels, not universal authorization for every account, country, plan, or installed program. Nor does it automatically make an API feature available in the consumer Gemini app.
The documentation consulted lists gemini-4-argon, gemini-3.8-flash, gemini-3.5-flash-lite, and gemini-3-flash-preview as compatible models. The final model’s name still identifies it as a preview model. Developers must check the actual model identifier selected for their project; simply choosing any Gemini-branded model is not enough.
What tasks can an agent perform?
In Google’s examples, agents can research information on websites, navigate pages, fill out repetitive forms, and test web-interface flows. In supported environments, they can propose clicks, scrolling, typing, keyboard shortcuts, and other mouse and keyboard actions. The documentation also covers browser, mobile, and desktop environments, each with its own supported action set.
Those examples describe automation possibilities, not guaranteed success or unrestricted access to websites, accounts, and files. A workflow can research prices without completing a purchase. Filling in an email is different from sending it: the final step has consequences that call for safety checks.
Who moves the pointer and runs the commands?
The developer must implement a repeating action loop. The API does not control the operating system by itself:
- The application sends the task, environment configuration, and a screenshot to the API.
- The model returns a proposed action as a function_call, such as click or type, and may include intent, an explanation of the step’s purpose, plus safety_decision.
- The client program checks the safety decision, converts coordinates for the screen, and executes the action with an automation tool such as Playwright only when permitted or confirmed.
- The application captures the updated screen, sends the outcome through function_result, and repeats the loop if more steps are needed.
The developer therefore determines the environment, process permissions, and code that actually acts. A click described by Gemini is not proof that the click occurred.
Which actions may be blocked or require permission?
Google documents seven built-in safety policy categories to guide decisions. A category defines a type of risk; it does not mean every instance always triggers the same approval dialog. Depending on context and configuration, an action may be allowed, require confirmation, or be blocked.
| Policy category | Examples of protected actions |
|---|---|
| FINANCIAL_TRANSACTIONS | Payments, retail checkout, and transactions involving regulated goods. |
| SENSITIVE_DATA_MODIFICATION | Unauthorized changes to health, financial, or government records. |
| COMMUNICATION_TOOL | Autonomous sending of emails, messages, and other communications. |
| ACCOUNT_CREATION | Creating new accounts on websites. |
| DATA_MODIFICATION | File changes, data sharing, and deletion of stored content. |
| USER_CONSENT_MANAGEMENT | Cookie banners and consent or privacy choices. |
| LEGAL_TERMS_AND_AGREEMENTS | Accepting terms of service and legally significant contracts. |
The table does not establish that a particular click will always show the same confirmation screen. Classification applies to the specific action; an application can impose additional restrictions.
How does human confirmation work?
When the API response contains a safety_decision whose decision is require_confirmation, the integration must pause that action and ask the person for approval. If the user agrees, the application performs the step and returns safety_acknowledgement in function_result. If the system classifies an action as blocked, it must not be executed. Confirmation is not merely polite wording: the program controlling the interface has to enforce it.
The documentation also includes an example of stricter developer-authored safety instructions requiring approval before sending messages, completing purchases, accepting terms, or handling CAPTCHAs and sensitive information. This is an example of additional configuration, not a universal list of events that the default mechanism always confirms. Custom safeguards should complement the API decisions.
What risks remain?
Screenshots may contain private information, while websites can display malicious instructions designed to redirect the agent, a threat known as prompt injection. Google provides optional screenshot scanning for injection attacks on the specified models, but this feature is disabled by default (false). Its guidance recommends isolated environments, limited permissions, allowlists for websites, and action logs for auditing.
Some safety policies can be disabled, yet Google states that a policy override does not necessarily prevent a require_confirmation response. For high-impact operations, sensitive data, or consequences that are difficult to reverse, it recommends close human oversight. GA is not certification that the tool is error-free, invulnerable, or safe on every site.
What does general availability not prove?
The October 30 release note confirms the tool’s GA status in both APIs, but does not, by itself, specify individual account eligibility, the price of each model, usage quotas, or Brazil-specific access conditions. These details must be checked for each project, including API billing rules, which are separate from a Gemini app subscription.
The verified conclusion is a documented developer tool with compatible models and configurable safeguards. This reporting includes no live execution, accuracy measurement, validation of a Brazilian account, or evidence that the system can complete every task without intervention.
