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.
- 01The browser is hostedThe application still manages sessions, approval events and user interaction.
- 02Origin permission is broadA website approval is not an enforced confirmation before every action.
- 03Choose the runtime from the riskUse stronger external controls where per-action approval must be guaranteed.
01 — The evidenceWhat changed on September 29 #
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.
02 — Practical implicationsWhat origin approval actually authorizes #
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.
If your requirement is that a person must approve every change before it happens, a prompt asking the agent to is not enough. Restrict the resources it can reach or use a browser runtime whose action controls you can enforce. 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.
| Digital Applied design checklist, informed by the official computer-use guide read October 1, 2026. | |
|---|---|
| Boundary | Question for the application |
| --- | --- |
| Website | Which origins may the session reach? |
| Account | What permissions does the signed-in identity possess? |
| Action | Which changes require an enforced human decision? |
| Result | What evidence proves the intended change happened once? |
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.
03 — Practical implicationsDesign approval handling as a complete flow #
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.
Continue within the intended scope
Show the task and destination, then record the decision against that session.
Keep the boundary intact
Explain the blocked step and preserve any work already completed safely.
End the pending work
Confirm that the task no longer waits for an approval that will never arrive.
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.
04 — Practical implicationsStart with a task that produces a draft #
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.
05 — Practical implicationsChoose the narrowest enforceable workflow #
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.
Test the approval boundary before adding write access
A hosted browser can simplify execution. A safe application still needs a clear account scope, complete approval handling and a reliable way to determine what happened. Prove those properties on a bounded task before delegating changes to valuable systems.