How does OpenAI computer use work in the Agents API?
AI Architect
Key takeaways
- OpenAI's 29 September 2026 changelog says computer use is available in the Agents API and runs in an OpenAI-hosted browser.
- OpenAI's computer use guide says each new website origin, including public sites, requires user approval even when network access is enabled.
- OpenAI's sign-in flow keeps credential entry in your application and supports email addresses, passwords, and verification codes, but not passkeys or QR-code sign-in.
- OpenAI's sessions guide says a completed turn still needs result inspection because session idleness alone does not prove that every tool step succeeded.
- OpenAI's architecture guide places function-tool handling and any self-hosted environment lifecycle on your application side of the boundary.
The important sentence in OpenAI’s current computer use docs is the one saying your application still handles website access approvals and sign-in. That turns OpenAI computer use into an approval-and-verification integration. My view is that teams should adopt it for supervised browser work, then reject the common idea that “hosted” means the trust boundary moved all the way to OpenAI.
What does OpenAI computer use actually host for you?
OpenAI hosts the browser session and the agent harness, which is the useful
part to stop operating yourself. The 29 September 2026
changelog says computer use
was added to the Agents API and can complete tasks in an OpenAI-hosted browser.
The architecture page
explains the wider boundary: OpenAI runs the harness, while your application
sends work, receives events, and handles function tools. The
computer use guide
then adds the browser-specific piece by requiring environment.type to be
openai_hosted with desktop enabled. So browser provisioning, screenshots, and
session execution move to OpenAI’s side. What does not move is the operational
decision layer around access, authentication, and result acceptance. That fits
the same hosted-runtime boundary described earlier in
what OpenAI’s Agents API manages: the
control plane is hosted, while the product-facing decisions stay in your code.
Where OpenAI computer use stops being "hosted"
Show as text
| # | Layer | Note |
|---|---|---|
| 1 | OpenAI-hosted browser session | Browser lives in OpenAI's environment. |
| 2 | Agent turn and browser events | Your app streams status and output. |
| 3 | Origin approval request | Public origins can still pause work. |
| · | Application boundary (breakpoint) | |
| 4 | Sign-in UI and credential entry | Users verify the destination in your app. |
| 5 | Result review and retry policy | Your app confirms the turn really worked. |
Why does OpenAI computer use still require origin approvals?
Because OpenAI treats origin access as a user decision. The computer use guide
states that “each new website
origin, including public websites” requires approval, and that enabling network
access does not approve those requests. That is the correction most launch
summaries skipped. A browser task can stall on a normal public page if your
application does not handle browser_origin_access approvals from
required_actions, present the origin and reason, and answer with approve,
deny, or cancel by request_id. The same page also says this approval does not
guarantee confirmation before every consequential click, which is a second
important limit. If you need a hard checkpoint before purchases or destructive
changes, OpenAI’s own guidance is to restrict the browser’s reachable resources
or use a runtime you control. That makes the real unit of work an approval loop
more than a simple browse command, closer to a reviewed workflow than to
traditional unattended browser automation.
The OpenAI computer use approval loop
Show as text
| # | From | To | Message |
|---|---|---|---|
| 1 | Your application | OpenAI session | Create session with computer_use. OpenAI starts the hosted browser. |
| 2 | OpenAI session | Your application | requires_action for browser_origin_access. Public origins trigger this too. |
| 3 | Your application | OpenAI session | Approve, deny, or cancel by request_id. Network access alone is not approval. |
| 4 | OpenAI session | Your application | Optional browser_authentication request. Main agent only, with fields or options. |
| 5 | Your application | OpenAI session | Submit credentials or cancel. Credential values stay outside model input. |
Why does OpenAI computer use keep sign-in in your application?
OpenAI’s sign-in flow is deliberately application-owned. The computer use guide says your application handles sign-in so users can choose a method and enter credentials outside the chat, and it spells out the supported methods: addresses, passwords, and verification codes are supported, while passkeys and QR-code sign-in are not. That boundary matters for both security and product design. The same page says submitted values stay outside the model input and are omitted from authentication response items in session history, which is the right default for secrets. It also says you should ask users to enter credentials only for a destination they can verify independently, and to cancel when the credential origin is missing or unfamiliar. So the browser session can reach a login screen, but trust still depends on your own sign-in UI and your own log hygiene. This matches the broader point in which agent actions need a human checkpoint: the meaningful control sits at the credential or write step. The place where the browser window runs matters less than the moment a task can touch an account or change real state.
What failure modes does OpenAI computer use create for operators?
The main failures are stalled approvals, unsupported authentication, and false
success. A stalled approval happens when the event stream is not being watched
or a request_id is mishandled, so the session waits on required_actions
instead of progressing. Unsupported authentication is the straightforward one:
the docs say passkeys and QR-code sign-in are outside the flow, so any site
that depends on them is an immediate mismatch. False success is the subtle
failure. The sessions guide
says an idle session alone does not mean the turn succeeded and tells you to
check whether the turn completed, failed, or was cancelled, then inspect the
output too. The computer use guide adds one more operational warning: if a
credential submission outcome is uncertain, refresh the session before
continuing and avoid automatic retries for credential submissions. My opinion is
that this makes computer use a poor fit for silent background work and a strong
fit for supervised tasks where pauses, verification, and human escalation are
already normal.
When should OpenAI computer use be your default?
OpenAI computer use should be your default when the task needs web navigation plus model judgment, and when your product already has a place to show approvals and gather sign-in. Reading a web console, checking settings in an admin UI, or carrying a human-reviewed browser task across several turns are good examples. Those are the cases where a hosted browser plus durable session state saves real engineering time. It should not be your default for every browser problem. Deterministic scraping, regression tests, and flows that depend on unsupported login methods still belong in a runtime you control, such as the patterns OpenAI documents in its computer use integration recipes. My view is simple: use OpenAI computer use when the hard part is reasoning over the page, not when the hard part is guaranteeing exact browser behavior. If the approval surface feels like the work, the docs are telling you something true about the product boundary rather than describing a bug.
Do this
Roll out OpenAI computer use safely
Start with the approval loop, because that is where most production failures and trust mistakes appear first.
Decide whether the browser task really belongs in a hosted agent
Use OpenAI computer use when the work needs agent reasoning over a live web interface. Keep deterministic scraping and regression testing in your normal automation stack.
Build a first-class origin approval path before the first task
The guide says public sites still trigger browser_origin_access requests. If your UI cannot approve, deny, or cancel those requests by request_id, the session will stall on routine navigation.
Keep sign-in outside chat and outside logs
Render the requested fields in your own UI, verify the destination, and submit values only through the dedicated authentication event. Never echo credentials in messages, analytics, or tool results.
Treat unsupported login methods as a product limit
Passkeys and QR-code sign-in are outside the documented flow. If a target site depends on them, reject the use case early or route it to a runtime you control.
Verify turn outcomes before acting on them
A session becoming idle is not enough. Check for turn completion versus failure, inspect the output, and decide whether the browser task actually produced the state your product needed.
Frequently asked questions
- Does OpenAI computer use mean OpenAI handles login for me?
- No. The computer use guide says your application handles sign-in so users can choose a method and enter credentials outside the chat. Submitted values stay outside the model input and are omitted from authentication response items in session history.
- Does enabling network access approve website visits automatically?
- No. The guide says each new website origin requires approval, including public websites, and that enabling network access does not approve those requests.
- Can OpenAI computer use handle every login method?
- No. The documented flow supports email addresses, passwords, and verification codes. The same page says passkeys and QR-code sign-in are not supported.
- Is a finished turn enough to trust the result?
- No. The sessions guide says to check the turn outcome and inspect the output because an idle session alone does not prove the work succeeded.