ChatGPT can finally wake up for work: an email triggers it, and a signed-in session lets it keep going

Conclusion

ChatGPT is beginning to look like an assistant that can wake up for work on its own.

On August 25, OpenAI closed two important gaps in Work. When cloud browser reaches a supported website's sign-in page, it can pause for the user to enter an account name, password and verification code through a secure form, then continue the rest of the workflow. Scheduled Tasks are no longer limited to waking up at a time on the clock: new Gmail messages, Slack channel messages and GitHub pull-request activity can trigger them directly.

Add the WebMCP Challenge launched on the same day, and a chain that previously required an email trigger, Zapier, RPA, browser automation and a language model is starting to collapse into one OpenAI product surface.

The phrase "go to work on its own" still needs boundaries. The model does not type or inspect your password for you. Not every website is supported. Payments, outbound messages and other consequential changes do not suddenly become unattended actions.

The first badge: a sign-in page no longer ends the shift

Earlier browser agents had an awkward kind of intelligence. They could search, click and fill forms, then hand the job back as soon as a page said "sign in." Yet the useful parts of CRM, insurance, logistics, recruiting and supplier systems almost always sit behind that wall.

In the new flow, ChatGPT Work's cloud browser pauses when it reaches a supported sign-in page. The user completes the account, password and two-factor steps in a secure form, then the agent resumes. OpenAI says credentials go directly to the remote browser. The model cannot see the username or password, and ChatGPT does not store those sign-in credentials.

The authenticated session can persist until it expires, so a later task may not have to start at the door again. OpenAI's own examples have moved beyond "look up a page" to finding a DMV appointment, signing into a utility account to compare plans, reconciling invoices and updating accounting records.

The second badge: Tasks move from periodic checking to events

Scheduled tasks used to behave mostly like alarms. You could ask one to check the news every morning or inspect an inbox every hour. The problem is obvious: a customer can reply at 9:01 while the agent waits until 10:00. Operational work often needs "start when the event happens."

The new event-triggered tasks use webhooks. Gmail can trigger on a new message and filter by sender or subject. Slack can respond to messages in channels that include @ChatGPT. GitHub can respond to supported pull-request activity in an authorized repository. They currently require Work and an eligible Plus, Pro, Business, Enterprise, Edu or some Healthcare account. Free, Go and FedRAMP workspaces are excluded.

This is more useful than polling more often. When a customer email, support-channel complaint or pull request changes, ChatGPT can read it, organize the context and prepare the next step without waiting for someone to remember to open a chat.

Put the two together and the digital employee starts to appear

Imagine an export-sales inquiry. A new Gmail message triggers Work immediately. The agent extracts the customer, country, product and quantity. It opens a CRM whose signed-in session still exists, checks the quote history, then brings a reply draft and delivery recommendation back to a person.

That line used to require a Gmail webhook, Zapier or Make, RPA, browser scripts and an LLM. OpenAI now wants Work to contain the event, interpretation, tools, browser and human approval in one place.

This is the strongest idea in the original draft. The news is not two more switches. It is the beginning of a product chain that looks like "event happens, reason, enter the system, act, ask for approval at the consequential step."

WebMCP adds the third piece: stop making the agent guess buttons

The WebMCP Challenge launched by OpenAI on the same day highlights another old weakness. If a browser agent only sees pixels and guesses which blue rectangle is the submit button, a redesign can break the workflow.

WebMCP is an experimental open standard that lets a website expose structured tools. A site can tell an agent how to search, update a record or change a shopping cart instead of requiring simulated mouse and keyboard actions. The built-in browser in the ChatGPT desktop app can already discover these site tools when both the account and page support them, and the tools can use the open page's current signed-in session.

This is not identical to Work's cloud browser. Site tools currently belong to collaboration with pages open in the desktop app's built-in browser. Cloud browser is a delegated task running on a remote computer. They have not yet become one seamless automation layer that works across the web.

Do not print the employee badge yet: three practical limits

First, each website still decides whether the agent gets in. OpenAI promises support on supported public and signed-in sites; security controls and anti-automation systems can block cloud browser traffic.

Second, access to a back office is not permission to change anything at will. Payments, booking confirmations, outbound messages and changes to external data may pause for human review.

Third, useful permissions raise the cost of mistakes. OpenAI's cloud-browser documentation explicitly discusses prompt injection, phishing and unintended actions, and says safeguards do not remove every risk. An agent with CRM and email sessions should begin with the minimum permissions given to a new employee, not an administrator account.

Who should try it now

The best first workflows have a clear trigger, require contextual understanding and leave the final action available for human review. Examples include organizing requirements after a customer replies, preparing a response after a complaint appears in Slack, or summarizing changes and risks after a pull request is updated.

Bad first workflows include automatic payments, deletion, price commitments or mass messages. Begin with reading, classifying, looking up and drafting. Keep sending, changing, purchasing and deleting behind an approval point.

Practical access also depends on plan and region. Cloud browser is available on paid plans in supported regions, excluding Free and Go. Event-triggered tasks in managed workspaces also depend on administrator permissions and app settings.

Our judgment

This update is larger than "ChatGPT received another feature" because it stops asking only how many intelligence points an agent is missing. It supplies the boring infrastructure that decides whether the agent can work: events, authenticated sessions, permissions, an execution environment and approval points.

It is not the final form of a digital employee, but it has moved beyond a chat box toward an early Agent runtime. A task can wait, be triggered, use an app, open cloud browser, continue with a signed-in session and return to a person for a consequential action.

This is not a death sentence for Zapier, Make or traditional RPA. Deterministic workflows remain more reliable, while agents are better at reading ambiguous information and preparing choices. OpenAI is nevertheless absorbing more of the automation value chain, which makes this a product line worth following.

What still needs watching

Early users need to learn more than whether a demo runs. Long-lived workflows can miss events, execute twice or pause silently when authentication expires. Production use will depend on run limits, approval delays, recovery behavior and audit logs.

WebMCP has its own cold-start problem. Structured tools become more reliable than button clicking only when websites choose to implement them and also design authorization, rollback and confirmation properly.

The final test is the result users care about: whether this removes three dashboards from their daily routine, rather than adding another agent dashboard that needs supervision.

Sources and evidence boundary

• Primary release notes: OpenAI's August 25 release notes explicitly add supported signed-in websites and webhook triggers for Gmail, Slack and GitHub pull requests;
• Primary product documentation: the cloud-browser guide supports the secure sign-in flow, session persistence, website limitations and consequential-action confirmation;
• Primary task documentation: the Scheduled Tasks guide supports eligibility, the three event sources, administrator controls and pauses for required approval;
• Primary standard and implementation documentation: the WebMCP Challenge and site-tools guide support website-exposed structured tools and the current desktop built-in-browser boundary.