Do your Grok Bots share one cloud computer and its logins, or does each bot get its own?

Your Grok Bots share one cloud computer, and they share its logins. The computer belongs to your account, not to an individual Bot. Files, browser cookies, signed-in sessions, and command-line credentials on that machine are available to every Bot you run. Each Bot gets its own screen, and its own conversation memory, but the screen is a work surface, not a security boundary. Between different users, isolation is strict. Between your own Bots, it is not.

That is the model in the current Grok Bot docs, and it is easy to misread the launch language. The announcement says Bots have a computer of their own and then, in the same breath, that they share a computer in the cloud. The docs page titled around the computer and apps is the precise version: one persistent computer per user, many Bots, many screens. If you put a credential on it for one Bot, treat it as available to the rest.

What is actually shared?

The computer-and-apps page lists four things that move with the machine rather than with the Bot name.

• Browser cookies and signed-in sessions.
• Files. Every Bot can see them. Durable project files are meant to live in a shared workspace at /workspace, in folders you can name clearly.
• Command-line credentials.
• The ability for one Bot to continue work another Bot saved.

Signing in for one Bot makes that browser session available to your other Bots. You usually do not sign in again for the next task, which is the convenience. It is also the leak inside your own account. A Bot you made for a noisy research job can open a site you logged into for a finance Bot, because the cookie jar is the computer’s, not the Bot’s. The docs say this directly: do not place a credential or file on the computer if another Bot on the account should not be able to use it.

Connectors do not create a private computer either. They are plugins from Marketplace, a structured way into supported services. You authenticate in the browser when the plugin asks, then attach a connector in chat. The underlying cloud computer is still the shared one. A connector the account installed is not a per-Bot vault. If a Bot needs a login the others must not have, the documented answer is not “make another Bot.” It is “do not put that login on this computer.”

What is not shared, even on that one machine?

Conversation memory and learned context stay separate per Bot. The FAQ says stable preferences, role context, and summaries of prior work are what a Bot remembers, and that conversations and learned context stay per Bot. Shared files, browser sessions, and direct handoffs are how context moves between them. For a decision that matters, the same FAQ says to ask the Bot to check the current source instead of trusting memory.

Each Bot also has its own screen. Several Bots can use browser and desktop tools at the same time, and one Bot can run only one computer-use task on its screen at a time. You can watch a preview of clicks and navigation. The screens keep Bots from fighting over a single mouse. They do not keep Bot A from reading a file Bot B wrote, or from using a session Bot B signed in. If you need a mental picture, use two monitors on one login, not two laptops with two password managers.

Routines are owned by one Bot. A routine tells that Bot when to run a workflow, on a schedule or, where supported, after an event. The skill it runs can be available across your Bots, though a Bot may still need the connector or login, which on this architecture means the shared computer already has it. A skill is instructions. It is not a separate filesystem. Installing a private skill and enabling it per Bot changes who is offered the procedure. It does not split the disk.

Deleting a Bot does not wipe the computer. The FAQ says deletion removes that Bot’s active profile, conversation, and routines. Because Bots share a computer, files and logins on it may remain. Backend retention follows the applicable Cursor terms. If you might need the work later, the docs say to hide the Bot instead of deleting it. Hiding does not create a private disk either. It takes the teammate out of the way and leaves the machine.

Where does the boundary between people sit?

Between users, the docs say isolation is strict. Your account’s computer is not your teammate’s computer. That is the line that makes “my Bots share logins” a different sentence from “the company shares one browser.”

There is a team exception worth reading before you assume a teammate’s Bot is a foreign machine. The Cursor Grok Bot docs say that when you chat with a teammate’s Team Bot, it usually works on your computer too. I am treating that as a handoff onto the computer of the person who is chatting, not as a hole that lets every teammate browse your files uninvited. If your account’s admin docs say something narrower, believe the admin page for your plan. I am not going to guess enterprise network controls from a personal-account paragraph. Directory-group scope, locks, and egress rules are documented as Enterprise. On a personal account, the boundary you can actually administer is: one computer for your Bots, and other people’s computers are not yours.

Your laptop or desktop is also not this computer. Execution on the local machine is a separate capability. The default is ask every time. Never allow is the right setting unless a Bot has a specific reason to touch local files. Those settings do not stop cloud work. A prompt that asks whether Grok Bot and all Bots may run commands on your local computer is an account-wide local grant, which matches the cloud model: your Bots are a roster, not isolated tenants. Always allow and never set that local policy for every Bot. Allow once and deny once are the narrower taps. A team admin can cap the setting. The team’s stricter policy wins.

What should you put on the shared computer, and what should you leave off?

Put the logins that every Bot in the roster is allowed to use. A shared workspace folder for a project several Bots hand off is the design. The overview says the sharing is what makes handoffs work without repeating setup. A sales Bot and an ops Bot on the same account can continue each other’s files because the files were never private. Use that when the jobs are one person’s jobs.

Leave off anything a second Bot must not see. A personal mailbox, a bank, a production admin session, a password manager export, an SSH key you use for unrelated hosts. The docs do not offer a per-Bot credential safe on the cloud computer. Command-line credentials are shared. Browser sessions are shared. If two jobs need two trust levels, they need two accounts, or one of the jobs should not be given to a Bot on this computer. A second Bot is the wrong tool for a second security boundary.

Leave human steps human. A site can still block automation, expire a session, or require a password, a passkey, two-factor, a CAPTCHA, or a payment. The Bot is supposed to hand those to you rather than work around them. That pause is not a per-Bot sandbox. Once you complete the login, the session joins the shared browser. Approve the login only if every Bot on the account may hold it.

Auto Review is the other control, and it is not isolation. It can let an action proceed, require approval, or deny it, for shell, plugins, computer use, automation writes, and delegation. Ask-first wins over allow-automatically. Rules live with the account and, on Enterprise, with the team. A rule that says ask before sending external email applies because you wrote it, not because Bot B cannot see Bot A’s browser. Write the rule if the shared login makes a send possible. Do not expect the Bot’s name to enforce it.

How do you check which story you are in?

Sign a test site into one Bot’s browser task. Ask a different Bot on the same account to open the same site and tell you whether it is already signed in. If the docs are right, it is. That is the whole product, not a bug. Then ask each Bot, in its own chat, what it remembers about a preference you told only the first one. Conversation memory should not automatically be the other Bot’s memory. Files and a direct handoff are how you move that context on purpose.

If the second Bot is signed in, stop storing anything on that computer that only one of them should hold. Delete the leftover login from the shared browser if the experiment went too far, and remember that deleting the Bot you used for the test may leave the file and the cookie behind. The computer outlives the teammate you removed.

Your Grok Bots do not each get a cloud computer. They share one, including its logins, and they keep separate chats and separate screens. Other users get their own computer. Your laptop is a different machine with its own approval switch. The Bot’s name is a role. It is not a wall.