--- title: How does OpenAI computer use work in the Agents API? url: https://deepthinkingai.org/openai-computer-use-agents-api/ published: 2026-10-04 author: Shekhar Singh topic: AI Engineering tags: openai, computer-use, agents-api, browser-automation, approvals site: DeepThinking AI --- # How does OpenAI computer use work in the Agents API? **Summary:** OpenAI computer use runs the browser in an OpenAI-hosted environment, but the docs say your application still handles origin approvals, sign-in, and turn verification. Even public websites need explicit origin approval, and credential submission stays outside model input, so the real integration job is approval handling rather than browser scripting. ## 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](https://developers.openai.com/api/docs/changelog) says computer use was added to the Agents API and can complete tasks in an OpenAI-hosted browser. The [architecture page](https://developers.openai.com/api/docs/guides/agents-api/architecture) explains the wider boundary: OpenAI runs the harness, while your application sends work, receives events, and handles function tools. The [computer use guide](https://developers.openai.com/api/docs/guides/agents-api/tools/computer-use) 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](/what-openai-agents-api-manages/): the control plane is hosted, while the product-facing decisions stay in your code. **Where OpenAI computer use stops being "hosted"** 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 --- 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. The hosted browser removes browser provisioning, but the high-consequence checks still land in application code. The real engineering surface is approval handling, sign-in, and turn verification. ## 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** ```mermaid sequenceDiagram participant Yourapplication as Your application participant OpenAIsession as OpenAI session Yourapplication->>OpenAIsession: Create session with computer_use OpenAIsession->>Yourapplication: requires_action for browser_origin_access Yourapplication->>OpenAIsession: Approve, deny, or cancel by request_id OpenAIsession->>Yourapplication: Optional browser_authentication request Yourapplication->>OpenAIsession: Submit credentials or cancel ``` - Create session with computer_use: OpenAI starts the hosted browser. - requires_action for browser_origin_access: Public origins trigger this too. - Approve, deny, or cancel by request_id: Network access alone is not approval. - Optional browser_authentication request: Main agent only, with fields or options. - Submit credentials or cancel: Credential values stay outside model input. The browser task progresses only as your application answers approval requests. That is why computer use behaves more like an approval broker than a fire-and-forget browser runner. ## 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](/agent-controls-read-vs-write/): 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](https://developers.openai.com/api/docs/guides/agents-api/sessions) 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](https://developers.openai.com/api/docs/guides/tools-computer-use-integration). 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. ## Roll out OpenAI computer use safely Start with the approval loop, because that is where most production failures and trust mistakes appear first. 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. ## Sources - [OpenAI API changelog](https://developers.openai.com/api/docs/changelog). OpenAI, 2026-09-29 - [Computer use](https://developers.openai.com/api/docs/guides/agents-api/tools/computer-use). OpenAI, 2026-10-04 - [Architecture](https://developers.openai.com/api/docs/guides/agents-api/architecture). OpenAI, 2026-10-04 - [Run and continue sessions](https://developers.openai.com/api/docs/guides/agents-api/sessions). OpenAI, 2026-10-04 - [Computer use integration recipes](https://developers.openai.com/api/docs/guides/tools-computer-use-integration). OpenAI, 2026-10-04 --- Canonical HTML: https://deepthinkingai.org/openai-computer-use-agents-api/