OpenAI now documents a hosted-browser mode for its Agents API that lets an agent navigate websites and interact with browser interfaces, while requiring approval before it can access each new website origin. In the company’s guide, the browser runs in an OpenAI-hosted environment; the customer application creates the session, follows the event stream, handles website-access requests and then verifies the result before deleting the session. TechCrunch separately reported that OpenAI introduced an updated version of the Agents API that now supports computer use as part of a broader DevDay API update.
The practical shift is not just that an agent can click around a website. It is that browser automation is now described as a managed API workflow rather than a local desktop trick. According to the documentation, enabling access means adding a computer_use tool and setting the environment to an OpenAI-hosted desktop. The browser can be used to test a site, collect information or operate an application through its UI, but the application remains responsible for orchestration: it must start the session, listen for agent events and recover the same session if the connection drops.
What changes for builders
For teams building support agents, research assistants or website-testing workflows, the hosted model changes where complexity sits. The browser state lives in OpenAI’s runtime, but the policy decisions still live in the caller’s application. That means the integration boundary is not “let the model drive the browser” so much as “manage a long-running session, respond to approval prompts and confirm what happened.” In practical terms, this makes the feature more suitable for products that need reusable browser sessions and less suitable for one-off automation scripts that expect a fully unattended run.
The documentation also suggests a tighter operational loop than many browser agents have offered in the past. A task can span multiple session events, screenshots can be included, and the system expects the developer to review saved browser activity. That is useful for auditability and debugging, especially when an agent is asked to gather information from public pages or work through a multi-step website flow. It is also a reminder that the tool is still an agentic interface, not a deterministic browser macro: the model decides what to do next based on what it sees.
Why the approval gate matters
The most consequential part of the update is the approval layer. OpenAI’s docs say the browser must obtain user approval before accessing each new website origin, including public sites, and that simply enabling network access does not approve those requests. The guide also says applications should inspect the current required actions, surface the requested origin and reason, and then submit an approve, deny or cancel response tied to the session’s request ID.
That gate is important because origin approval is not the same as step-by-step confirmation. OpenAI’s documentation explicitly warns that if an application must guarantee confirmation before purchases, destructive changes or other consequential actions, developers should either restrict the hosted browser to resources that cannot do those things or use a browser runtime they control. In other words, the browser can be hosted, but the accountability model does not become fully automated simply because the agent is allowed to operate inside it.
That trade-off matters most for companies deciding whether to deploy an agent in customer-facing workflows, internal research, or compliance-sensitive operations. A hosted browser reduces infrastructure burden and can make session handling more portable, but it also introduces a dependency on OpenAI’s approval flow and on the developer’s own guardrails. If the task crosses into sign-in, purchases or data changes, the caller still has to decide whether the environment is constrained enough to be safe.
The useful reading for AI teams
For product and engineering teams, the story is best read as a boundary-setting update. OpenAI is making browser-based agents easier to run as an API capability, but it is also making the trust model explicit: the model can act, the host can route the browser, and the application must still decide when access is allowed and when human review is required. That combination is likely to appeal to teams that want browser-native agents for discovery, testing or information retrieval without giving up session control.
TechCrunch’s report places the browser update inside a larger set of DevDay changes, which suggests OpenAI sees computer use as part of a broader agent platform rather than a standalone feature. For readers deciding whether this matters now, the key signal is not the headline capability but the structure around it: hosted browser execution, session persistence, approval prompts and explicit warnings about consequential actions. Those details determine whether the feature can be used for a real workflow or only for a demo.
Watch for whether your use case needs simple web navigation or hard guarantees about what the agent can do. If the latter, the approval gate is the feature to scrutinize, because it shows exactly where OpenAI expects developers to keep control.
Source: developers.openai.com, techcrunch.com
Before adopting hosted browser computer use, map every origin the agent may touch and decide whether your workflow needs explicit human approval or a browser runtime you control.
