OpenAI Agents API Computer Use: Hosted Browser and Approvals

OpenAI’s Agents API now includes a hosted browser for computer use. That removes browser infrastructure from part of the application’s workload, but it does not remove the application’s responsibility for access and action controls. The most important implementation detail is that approving a website is different from approving every action the agent might take there.

Editorial note: Prepared October 1 as a September 29, 2026 dispatch, using the dated announcements cited below. Implementation guidance was checked October 1; the release claims below retain their September 29 context.

OpenAI’s dated API changelog adds hosted-browser computer use, website approvals and application-handled sign-in to the Agents API. The DevDay recap also lists computer use in Codex and ChatGPT Work for Pro 500 and Enterprise. Keep those subscription routes separate from API access: they are different ways to use the capability.

The existing managed-runtime guide explains the broader API. This update concerns browser interaction inside that runtime. It should not be described as unrestricted control of an arbitrary local desktop. A developer should first identify which part of the workflow requires a browser and whether an existing structured API would provide a narrower, easier-to-test interface.

The computer-use guide says each new website origin requires approval, including public sites. Network access alone does not grant that approval. The application receives an action-required event and handles the origin request. Crucially, the guide says origin approval does not enforce confirmation before individual actions, such as a purchase or destructive change.

An origin identifies a website boundary. It does not distinguish a harmless page read from a form submission in the same account. Before approving access, consider the authority attached to the session: a public page, a read-only account and an administrator account expose very different consequences even when the browser opens the same hostname.

The distinction also matters for audits. A log entry showing that a user approved a domain does not prove they approved a particular transaction. Record the authorization at the level your business process requires, and do not infer narrower consent from a broader technical permission.

The implementation guide uses an action-required session event with a browser-origin approval request. The app must present enough context for an informed decision and return an approval, denial or cancellation. Treat all three paths as normal application behavior. A denied request should not leave a background task waiting indefinitely or silently switch to another account.

For a first implementation, use a disposable session and a public destination. Verify that the application displays the requested origin accurately, associates it with the correct task and handles cancellation cleanly. Then test a task that encounters a second origin. Redirects and embedded services can change what a workflow needs; the user should not have to guess which request belongs to which step.

Sign-in is an application-handled flow. Keep credential entry separate from ordinary task instructions and follow the vendor’s documented mechanism. Do not put a password into the task prompt because it is a convenient way to make a prototype proceed.

A useful pilot might read an approved public catalogue and prepare a comparison in your application. The browser gathers information; a human checks the saved result. Use synthetic inputs and a fixed acceptance checklist so the team can distinguish navigation failures from wrong interpretation of the source.

Measure completed outputs, retries, elapsed time and human correction. A browser task that reaches the right page can still extract the wrong row or overlook a qualification. Save the source URLs and the relevant evidence alongside the draft. When the site changes, those records make it easier to determine whether the failure is in navigation, extraction or reasoning.

Before adding write access, test duplicate requests and interrupted sessions. The application should know whether an action has already happened before retrying it. Our permission guide and runtime comparison cover the controls around that transition.

Use the hosted browser when its permission model fits the task. If the requirement is a guaranteed human checkpoint before each consequential action, design for that requirement explicitly rather than relying on the agent to remember an instruction. Our AI transformation work starts with these acceptance and authorization boundaries before expanding browser automation.