Always-allow in Chrome is a session grant
ChatGPT can now drive the Chrome profile where you're already signed in. Before someone clicks Always-allow on admin, money, CRM, or email, decide which origins stay Allow-once only.
Treat Always-allow and Allow-for-this-site on a work origin as a standing cookie-and-session grant, not a convenience click. ChatGPT's Chrome computer use runs in the signed-in profile; the demos say stop before submitting, but Always-allow and Allow-for-all-sites remove the pause at the origin. Name which origins stay Allow-once, which action classes always need a human click, and who owns Enterprise Browser Use policy—before the extension lands on work browsers.
The prompt that used to be a pause
Someone on your team opens Chrome the way they always do. Gmail is signed in. So is Salesforce. So is the admin console for the store, the bank tab from this morning, the internal tool that only works because the cookie is still warm.
They install the ChatGPT extension. OpenAI announced it on October 15, 2026: computer use for anyone who uses Chrome—look across open tabs, fill forms, send messages, download files, group tabs, and keep a full ChatGPT side panel beside the page. The learning docs say ChatGPT can read and act on sites where you're already signed in. LinkedIn, Salesforce, Gmail, internal tools. Built-in @Browser keeps its own browser state. @Chrome and the extension use the regular signed-in profile.
Then the first permission prompt appears. Allow once. Allow for this site. Allow for all sites. Decline.
That used to feel like a UI detail. It isn't. On a signed-in work origin, the difference between Allow once and Always-allow is the difference between a pause and a standing grant.
What shipped, and what the demos quietly assume
The product story is easy to like. Chat across open tabs and gather what you need. In Work mode, control Chrome tabs—send messages, fill forms, download files, organize groups. The side panel keeps Chat or Work next to the site you're on. Example prompts in the launch thread include filling a registration form and stopping before submit, filling a dentist form in Chrome, comparing open tabs, and drafting an email from what's already open. The extension is available for all ChatGPT plans.
Permissions are explicit at the prompt: Allow once, Allow for this site, Allow for all sites, or Decline. Settings > Computer Use is where you manage the allowlist and blocklist. In the docs, Allow for all sites is labeled Elevated Risk. Browser history access is Elevated Risk too, and history doesn't get an always-allow option.
Enterprise workspaces get a separate control surface. Admins can disable Browser Use through the Chrome extension, set site rules with a default of Allow or Block, control uploads, downloads, and CDP, decide whether members may save Always-allow approvals, and turn auto-review on or off. A member's Always-allow cannot override an admin restriction.
None of that is a review of whether the feature is "worth it." The operating question is narrower: when you let an agent drive the browser where the sessions already live, which clicks are you willing to make permanent?
Decision guide
Allow once vs Always-allow on a signed-in origin
| Consideration | Allow once | Always-allow / Allow for this site |
|---|---|---|
| What you grant | Use this origin for this turn; ask again next time. | Use this origin again without asking; the signed-in session stays in play. |
| Where it hurts | Slower the first few times on a new host. | Admin, money, CRM, or email origins become a standing cookie-and-session grant. |
| Fit with "stop before submit" | Keeps a gate at the origin even when the task later pauses before a write. | Removes the origin gate; the in-task pause has to carry more of the safety load. |
| House default for work browsers | Default for high-stakes hosts until a named owner says otherwise. | Only after an allowlist review—or blocked by Enterprise site rules. |
| Allow for all sites | Not on the table for work profiles. | Docs label it Elevated Risk; treat it as off for anything with real sessions. |
Always-allow on a signed-in origin is a standing session grant, not a convenience click.
Always-allow is a grant to the origin, not a favor to the task
People click Always-allow because the task is annoying the first time. Fill the form. Draft the email. Pull the export. The next time, they don't want the dialog.
What they just did on admin.example.com, mail.google.com, or the CRM origin is not "remember this form." It is "this agent may use this origin again without asking." The cookies and the signed-in session are already there. The grant is the standing permission to act in that context.
The demos keep a human in the loop at the end: stop before submitting. That pause is the product's safety story for consequential writes. Always-allow and Allow-for-all-sites don't delete every confirmation inside a task, but they remove the gate at the origin. If the origin is where money moves, mail goes out, records get written, or admin settings change, that gate was doing real work.
This is a different problem from other people's agents hitting your public tools. Here the agent is yours, running in your signed-in Chrome. It is also tighter than a generic permission matrix: the news is the signed-in profile plus Always-allow as a durable site grant.
Say it out loud before anyone clicks: Always-allow on a signed-in origin is a standing session grant.
Name three decisions before the extension hits work browsers
Don't wait for the first scary prompt in a real CRM tab. Write three lists while the browser is still quiet.
1. Origins that stay Allow-once only. Admin consoles. Banking and payments. Payroll. Email. The CRM where deals and contacts get written. Identity providers. Internal tools that can change production state. Anything where a wrong click is expensive or hard to undo. Those hosts stay off the allowlist until a human re-approves each time—or they stay blocked in Enterprise site rules.
2. Action classes that always need a human click. Submit. Send. Download bulk exports. Pay. Delete. Change roles or permissions. Publish. Even when a site is allowed for reading or drafting, these writes stay behind a person. The launch demos already model "stop before submitting"; make that the house rule for the classes above, not a cute example.
3. Who owns Browser Use policy. Not "IT eventually." A named owner: security, IT, or an ops lead with authority to set Enterprise defaults, site rules, upload/download/CDP limits, and whether Always-allow is even available. They publish the allowlist, the blocklist, and the review path when someone needs an exception.
If you can't name those three in one sitting, the extension is not ready for the work profile.
How the work moves
Before the extension lands on work Chrome
- List the five origins
Mail, CRM, admin, payments, identity—plus any internal tool that can change production state.
- Mark Allow-once or Blocked
High-stakes hosts stay off the allowlist; research hosts can be Allow for this site only after review.
- Name human-click actions
Submit, send, download, pay, delete, role changes, publish—always a person, even on an allowed site.
- Assign Browser Use ownership
One named owner for Enterprise defaults, site rules, Always-allow availability, and exceptions.
- Set Enterprise levers
Extension on or off, default Block with allowlist, uploads/downloads/CDP limits, no Always-allow on money/mail/CRM/admin.
- Tell the team the rule
Publish the lists where people will see them before the first permission prompt in a real tab.
Put the enterprise controls to work, or leave the work profile alone
For ChatGPT Enterprise, the admin docs are the real product for this decision. You can disable Browser Use through the Chrome extension entirely. You can set default site access to Block and allow only approved origins. You can separately control uploads, downloads, and debug/CDP. You can stop members from saving Always-allow approvals, or restrict saved approvals by site. You can disable approvals across all sites. Auto-review can be on or off by workspace or by site.
Use those levers in that order of strength:
- Off on work browsers until the three decisions above are written.
- Default Block with an allowlist of low-stakes origins for research and drafting.
- No saved Always-allow on money, mail, CRM, admin, and identity hosts—or no Always-allow at all until you trust the review path.
- Upload/download and CDP locked down where a bulk export or debugger access would be a breach by another name.
Personal Chrome profiles and personal ChatGPT plans will move faster than work ones. That's fine. The failure mode is the work profile with the real sessions getting Always-allow because someone was in a hurry.
Ship the rule before the first Always-allow
This week, do one concrete thing. Pick the five origins your team lives in—mail, CRM, admin, payments, identity—and mark each Allow-once only or Blocked for Browser Use. Write the action classes that always need a human click on a single page everyone can find. Name the person who owns the Enterprise Browser Use policy and when they will review exceptions.
If you're building agents that touch real systems, the same discipline shows up in how we design AI applications and agents: bounded tools, visible state, and a human at the consequential write. If the agent is filling forms and moving through web apps your customers already use, that sits with web applications too—permissions and session boundaries are part of the product, not a settings afterthought.
The Chrome launch makes the old abstract advice urgent. The sessions are already in the tabs. The pause is optional. Decide which pauses stay before someone clicks Always-allow for you.
Related work: Spin:Market (agents).
We build alongside the people doing the work.
Bring us the problem you’re thinking about.