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.
Written October 1, 2026 and dated September 29, 2026, 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.
- 04Log the decision at the level the process needsA record that a user approved a domain does not show they approved a transaction; record consent at the boundary your business process requires.
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 pause 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.
| 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 — ApprovalsDesign 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 — The pilotStart 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 — The decisionChoose 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.
06 — The failuresFour approvals that approved the wrong thing
The guide’s central distinction, that approving a website is not approving every action there, has several ways to be lost. The illustrative applications below each lose it once. They are design examples drawn from the computer-use guide’s own statements, not deployed systems.
The origin as the action
A user approves a retailer’s origin so the agent can compare prices. The agent completes a purchase in the signed-in account. The guide says origin approval does not enforce confirmation before individual actions, and nobody added the control that would.
The pause as the control
The task prompt tells the agent to pause before any change. On a long task the instruction is not followed once, and a destructive change goes through. A prompt is advice to the agent; the guide’s answer is to restrict the resources or use a runtime whose action controls you enforce.
The denied request left hanging
A user denies a second origin that a redirect introduced. The background task waits for an approval that will never arrive, and the next morning the work is neither done nor stopped. Denial was never designed as a normal path.
The domain log as consent
An audit asks who approved a transaction. The log shows a user approved the hostname. The business process required consent to the transaction, and a broader technical permission was recorded in its place.
Each application had an approval and the approval covered a different boundary from the one the process needed. The session record in the next section writes the boundaries down separately.
The four map onto the website, account and action rows of the boundary table above, with the first and fourth both sitting on the action row. That is where the guide’s central sentence lives: origin approval does not enforce confirmation before individual actions. An application that reads that sentence as a limitation of the hosted browser has read it correctly, and the answer is the one the callout gives, restrict what the session can reach or use a runtime whose action controls you enforce, rather than an instruction the agent is asked to remember.
07 — The recordA session record for a browser task
The boundary section’s table asks four questions, about the website, the account, the action and the result, and the record for a session answers each as the task runs. Origins: each requested, with the context shown to the user, the decision returned, approval, denial or cancellation, and the task step the request belonged to, so a redirect’s second origin is not confused with the first. Account: the identity signed in and the permissions it holds, since a public page, a read-only account and an administrator account expose different consequences at the same hostname, with sign-in handled through the application’s documented flow and never through the task prompt. Actions: each consequential action attempted, whether an enforced control stood in front of it, and what happened. Evidence: the source URLs and the relevant content saved beside the draft, so a later failure can be placed in navigation, extraction or reasoning. And retries: whether an action had already happened before any repeat, which the pilot section asks to be tested before write access is added.
An illustrative record for a catalogue-comparison pilot reads: origins, the approved public catalogue, then a second origin from an embedded pricing service, requested with its context and denied, the task completing without it and saying so; account, no sign-in, a public page; actions, none consequential, the task restricted to reading; evidence, the product URLs and the rows extracted, saved with the draft comparison; retries, one interrupted session resumed from the saved evidence without repeating the fetches.
The record answers the audit question the boundary section raises. If the business process required consent to a transaction, the actions line shows whether such consent was obtained and enforced, and the origins line shows that a domain approval was something else.
Keep the record per session and mark each task within it, because the guide lets follow-up tasks reuse a session and its browser state, so an earlier task’s sign-in can still be in place for the next, and the record is what shows which task each approval and sign-in belonged to.
Which origins may the session reach? What permissions does the signed-in identity hold? Which changes require an enforced human decision? An approval answers one of the three, and the record says which.
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.