ChatGPT Work Crosses the Login Barrier, but Keeps Users at Payment and Booking Checkpoints
The new sign-in path turns the cloud browser from a public-web helper into an agent that can work inside accounts. Its safety design now depends heavily on what the agent can do after entry.
Listen to this story
The audio brief
Story brief
3 key pointsOpenAI is extending ChatGPT Work from public websites into authenticated browser sessions, expanding tasks such as account checks, reimbursements, and appointments. Users still enter credentials themselves through a remote-browser form, while the model remains unable to see or store passwords. The larger risk boundary comes after login: Work can use the session until it expires or site data is cleared, but must...
- 01
Credentials go directly to the remote browser; ChatGPT does not see or store passwords or two-factor codes.
- 02
A separate review model checks the login destination for phishing or deception before the credential form appears.
- 03
Authenticated sessions can persist until expiry or the user clears that site’s browser data.
ChatGPT Work can now continue tasks after a user signs in to a website, allowing OpenAI’s cloud browser agent to work in private account sessions. OpenAI says passwords stay hidden from the model, while users retain approval over bookings, payments, and other actions that may be hard to undo.
A route past the sign-in page
When Work reaches a supported login page, it pauses for the user to enter a username and password in a secure sign-in form and complete two-factor authentication. OpenAI says those credentials go directly to the remote browser, are not stored by ChatGPT, and remain unavailable to the model.
That changes the range of work the product can attempt. Public-web research does not require an account, but checking a reimbursement, opening an account dashboard, or seeking an appointment generally does. After sign-in, Work can resume in the authenticated browser session.
Password isolation is not account isolation
The remote browser has its own cookies, site permissions, and logged-in sessions. It does not use the tabs, history, or credentials in a user’s local browser, so a user must sign in again even if the same site is already open on their device.
The distinction matters after login. A password withheld from the model does not prevent the agent from acting in an account session. Work therefore asks for approval before confirming a booking, making a payment, or taking another potentially difficult-to-reverse action.
OpenAI also says a separate review model checks the requested login and destination for phishing or deception before showing the credential form. Users can inspect the address, preview the form, or open the live page; OpenAI advises against placing passwords, security codes, or payment details in chat.
Useful access, uneven reach
Authenticated sessions can remain available for later tasks until they expire or the user clears that site’s browser data. The persistence can reduce repeated sign-ins, but it also extends the period in which the remote browser has account access.
Where Work may still stop
- A website can block automated traffic.
- An authentication method may not be supported.
- Some transactions may require the user to take control of the remote browser.
The feature is rolling out on web and mobile for Plus, Pro, and Business users, subject to account eligibility, region, and workspace permissions. OpenAI introduced Work on July 9 for longer jobs across websites, connected apps, local files, and finished deliverables; authenticated browsing pushes that design beyond the public web.
Editorial analysis
Our Read
The consequential shift is not that ChatGPT Work can fill another form. It is that OpenAI has created a path for its agent to operate within an account while keeping the password outside the model’s view. That makes session controls, destination checks, and confirmation moments more important than the chat interface alone. The evidence to watch next is how often users must take over on real sites, especially where automation is blocked or an authentication method is unsupported. Those limits will determine whether logged-in browsing becomes a routine workflow or remains a narrow convenience feature.
