Grok Bot tests Chrome cookie imports and local egress routing

Why it matters

Cookie imports and local network routing could remove two common failure points for cloud agents: repeated logins and blocked data-center traffic. They also give Grok Bot broader access to a user's authenticated sessions, all shared across one cloud computer.

SpaceXAI is testing Grok Bot controls that would import signed-in Chrome sessions into its cloud computer, route that computer's internet traffic through a user's desktop, and distinguish between local machines connected to the agent.

A screenshot posted Thursday by @blankspeaker shows a Computer settings panel with three sections: a named current computer, an "Import cookies from Chrome" button, and a toggle labeled "Route egress through this desktop." The panel also lets the user decide whether Grok Bot can execute work on the local computer.

The screenshot is a look at the plumbing SpaceXAI needs to make a cloud agent behave like the person operating it. Grok Bot can already work inside a persistent Linux virtual machine equipped with a browser, filesystem, and terminal. The harder product problem is giving that machine practical access to websites that expect a familiar login, device, network address, or physical security key.

SpaceXAI launched Grok Bot in early beta on August 11th, pitching it as a collection of always-on agents that can work across applications and continue after the user's laptop closes. SpaceXAI said Grok Bot grew from an internal prototype used for sales outreach, marketing, office operations, and software work.

Moving the user's identity into the cloud

The cookie-import control shown in the screenshot would copy authenticated Chrome sessions into the browser running on Grok Bot's cloud VM. That could spare users from signing into each service again inside the agent's computer, particularly when a workflow spans several websites.

SpaceXAI's current setup documentation tells users to take control of the cloud browser when Grok Bot encounters a password, passkey, two-factor prompt, or CAPTCHA. Once completed, that browser session persists and can be used by other Bots assigned to the account. Importing Chrome cookies would compress much of that setup into a single transfer.

That convenience carries a broad access grant. SpaceXAI's Grok Bot overview says every Bot belonging to a user shares one cloud computer, including its files, browser sessions, and application logins. Separate Bots do not create separate security boundaries. A Chrome session imported for one workflow could therefore be available to the user's entire Bot roster on that shared machine.

SpaceXAI's security guidance tells users to sign out of services when access is no longer needed, remove sensitive files, and revoke connector authorizations. It also recommends keeping publishing, purchases, deletions, production changes, and other consequential actions behind approval gates.

Making a cloud VM look local

The egress option addresses a separate source of agent failure. Websites frequently treat traffic from cloud data centers differently from traffic arriving through a person's usual home or office connection. That can trigger additional login checks, invalidate sessions, produce location mismatches, or block the agent outright.

SpaceXAI's enterprise documentation describes local egress routing as a beta setting. SpaceXAI says it can help when websites block Grok Bot's data-center IP addresses and when sessions are interrupted after the cloud computer's network address changes. The screenshot says users should enable egress before importing cookies for location-based sites.

Routing through a desktop also makes the local machine part of the agent's network path. The screenshot indicates that a new Grok Bot computer must be provisioned with an egress tunnel before the control can be used. If the desktop is offline, that route may be unavailable even though ordinary Grok Bot tasks continue in the cloud.

The named-computer field appears aimed at users who run Grok Bot from multiple desktops. @blankspeaker described the test as allowing users to specify which computer the Bot should use. SpaceXAI already separates permissions for the cloud computer from permissions to execute commands on the Mac or Windows machine in front of the user. Its security documentation says local execution defaults to requiring approval each time, with options to allow or refuse it.

The tests surfaced one day after SpaceXAI expanded Grok Bot access to SuperGrok, Cursor Pro, and all Cursor Teams plans. Wider distribution raises the cost of login friction: every additional user must connect the agent to the websites and accounts where useful work actually happens.

Cookie transfer, local routing, and computer selection are less visible than a new model release. They determine whether an agent can complete a browser workflow without repeatedly stopping for authentication or getting rejected as cloud automation. They also move more of the user's active digital identity into Grok Bot's shared computer, making permission design and session cleanup central parts of the product rather than administrative details.