Use apps

Apps are the outside services your agents can work with. Google's are built in: Gmail, Google Drive, whose files include Docs, Sheets and Slides, and Google Calendar. So are Microsoft's Outlook Mail and Outlook Calendar, and Linear, Sentry and GitHub, whose tools come from each vendor's own MCP server. Slack is the exception to what follows: an owner or admin connects it once for the whole workspace, and any agent the workspace grants it may use it. Any remote MCP server can be added as a custom app, for the workspace or just for you. An app you install belongs to you. It signs in with your own account, it is used only by your own agents and only for what you grant them, and nobody else in the workspace can use it or see what it produces.

For what Guest Machines reads, keeps and shares when you connect Google, see the privacy policy.

How apps work

1. A workspace owner or admin enables an app in Settings → Apps. Enabling gives nobody access. A personal workspace has no enable step: every app is available.
2. You install it from Apps in the sidebar, signing in with your own account.
3. You grant it to your agents, one agent and one operation at a time.

Enable an app for the workspace

Owners and admins open Settings → Apps and choose Enable next to an app. Members see the same list, read-only.

• Disable pauses the app for everyone at once, including runs already in progress, and nobody can install it while it is off. Every member's install, account, selections and agent permissions are kept, so enabling it again restores them without asking anyone to sign in again.
• Remove uninstalls the app for every member: their agents lose it, its triggers stop, and what they selected for it is forgotten. A Google account that no other app uses is signed out, and each member is signed out of Linear, Sentry or GitHub. To use the app again, enable it and have each member install it again. If a removal is interrupted, the app shows Removing; choose Finish Removing.
• Tool Limits sets what every member's agents may do with each of the app's tools, whatever their own permissions allow. See limit an app's tools.

Limit an app's tools

Once an app is enabled, owners and admins choose Tool Limits next to it and set each tool to:

• Allow: members decide with their own agent permissions, including Approve Each Use. This is where most tools start.
• Needs approval: a person approves every call, as if Approve Each Use were on for every agent. A run set to No Approvals still asks nobody.
• Blocked: no agent in the workspace can use the tool. It isn't offered to the agent at all.

Sending email, changing calendar events, and changing, commenting on or posting to Linear, Sentry or GitHub always need a person's approval, so those tools start at Needs approval and can't be set to Allow; you can still block them. Choose Save Limits to apply your choices.

Limits reach runs already in progress at their next call: a blocked tool's call is refused and the agent carries on without it, and a run that would call a tool that now needs approval pauses for a replan, which then asks. A tool added to the app later starts at its default until you set it. Disabling the app keeps its limits; removing it forgets them. A personal workspace has no tool limits.

Install an app

1. Open Apps and choose Install next to the app.
2. If you already have a Google account here, choose which one the app should use, or Another Google account. For Gmail and Google Calendar, choose which permissions to ask Google for, then check I Authorize These Permissions.
3. Choose Install with the app's name. Google asks you to sign in and approve. If the account already granted those permissions, the app is installed right away.

Installing an app, selecting a file or selecting a calendar gives no agent access on its own. You grant access per agent on the app's page; see give an agent access.

Each app's page shows whether it is ready, with the step it needs when it isn't:

• Needs permission: Google hasn't granted every permission you asked for. Choose Ask Google Again. Agents can use only what Google granted.
• Reconnect required: Google asked to confirm your account again. Choose Reconnect, then resume paused runs from their run page.
• Signed out: the account was disconnected. Choose Sign In Again; agents keep their saved permissions.
• Paused by workspace: an owner or admin disabled the app. Everything is kept and works again when they enable it.
• Needs admin approval: your Microsoft 365 organization must approve Guest Machines before you can sign in. See if your organization must approve Guest Machines.
• Needs setup: the app isn't set up on this server yet, so nobody can install it until the platform administrator finishes its setup.

Google

All your Google apps sign in with the same Google account unless you choose another. Each app asks Google only for its own permissions.

Google Drive

On Google Drive's page, choose Select Files, then Open Google Picker, and pick the Docs, Sheets and Slides agents may work with. Only the files you pick are connected; picking a folder never grants access to what is inside it. New files and copies an agent creates are saved in your My Drive.

Gmail

Reading, drafts and sending are separate permissions. Choose them when you install Gmail, or add one later on Gmail's page with Allow Gmail Reading, Allow Gmail Drafts or Allow Gmail Sending. Each one explains what it covers and asks you to confirm. Reading covers your whole mailbox except spam and trash. Sending alone doesn't let an agent read your mail.

Google Calendar

Event details, availability and changes are separate permissions. Choose them when you install Google Calendar, or add one later with Allow Calendar Event Reading, Allow Calendar Availability or Allow Calendar Changes. Then choose Select Calendars, pick up to 50 calendars and choose Save Calendar Selection. Availability shows only when you are busy, without titles, descriptions, locations or guests.

Your Google accounts

Google accounts on the Apps page lists the accounts your apps sign in with and which apps use each one.

• Use Another Account on an app's page moves that app to another account. Add Another Account on the Apps page signs in with a new account for the app you choose. Agents keep their permissions on the old account but can't use the app there until you grant it to them on the new one.
• Reconnect appears when Google needs you to confirm an account again.
• Disconnect removes an account. Every agent loses access immediately, and your file and calendar selections are cleared. The apps that used it stay installed and ask you to sign in again.

Linear, Sentry and GitHub

Linear (issues, projects, cycles and documents), Sentry (issues, events and traces) and GitHub (repositories, issues and pull requests) are built in, and their tools come from each vendor's own MCP server. Each member signs in with their own account, and the app can be granted only to a private agent you alone own.

1. Open Apps and choose Install next to the app, then Install and Sign In. The vendor asks you to sign in and approve, then sends you back to the app's page, which says Signed in. An app whose sign-in expired or was revoked shows Sign in again; choose Sign In Again.
2. The app's page lists every tool it offers, in Reads, Changes and Comments and posts. Each says whether it Asks a person every time or whether you choose, and whether it runs Only in work you start.
3. Under Agents, choose one of your private agents, or on the agent's Tools page, under Apps, choose the app. Then choose how its calls run:
   • Guest Machines calls it: the agent gets only the tools you check. A new grant starts with every read. Check Approve Each Use on a read to have it ask you each time; changes, comments and posts always ask. For GitHub you can check Only the Repositories Named Here and list them, one owner/repository per line; for Sentry, Only the Organizations Named Here. A search across every repository or organization can't be held to some, and neither can creating a repository, so leave those out to limit them. Check Allow Unattended Use to let your private automations and the app's triggers use it too: the tools not marked Only in work you start, which are the reads, and for GitHub every change but merging and creating a repository. Changes still wait for you to approve each one in the run.
   • Model provider calls it: the agent's model calls the vendor's server itself, with every tool that asks nobody and names no repository or organization. The agent's model must support MCP servers. Private automations and triggers never use an app this way.
4. Choose Grant with the app's name, or Save Access to change a grant. Remove with the app's name takes it off the agent.

When you grant tools for Guest Machines to call, it first checks which of them your account on the app offers, and a tool it doesn't offer can't be granted. The agent's edit page doesn't list these apps among its custom apps; it says how many you granted in Apps.

When the vendor changes a tool

Linear, Sentry and GitHub change their tools from time to time. When Guest Machines is about to call a tool you granted and finds the vendor changed it, it sends nothing, and the run that found the change can't use the app any more. Your grant then takes the tool as the vendor offers it now, or holds it:

• Taken: a change that can't let a call do more, such as a new description or an argument that's now required. You don't need to do anything.
• Held: a change that may let a call do more, such as a new argument or one that's no longer required, and a tool the vendor stopped offering. The agent's runs leave the tool out until you confirm, and its other tools run as before.

The grant shows how many tools are waiting with to confirm, and lists each one with what changed. Choose Allow Changed Tools to let the agent use them as the vendor offers them now; a tool the vendor no longer offers is taken off the grant. To leave one out instead, uncheck it and choose Save Access. If the vendor changes the tools again before you save, the save stops and the grant shows the new changes, so you only confirm what you've seen. A private automation or trigger that uses a held tool pauses; once you confirm, review it again to turn it back on. A grant the model provider calls isn't held: the provider uses the tools as the vendor offers them.

Uninstall takes the app away from all your agents, stops its triggers and signs you out of the vendor. GitHub shows Needs setup until the platform administrator registers Guest Machines with GitHub.

What GitHub checks for you

Guest Machines checks some GitHub calls itself, before anyone is asked to approve them and whatever the run's approval setting:

• Arguments the app refuses. A call that sets an argument the app never allows is refused before anything is sent, and the run is told why. GitHub's symbolic links can't be changed through the app, so a file change that asks to write through a link is refused, and the run is told to replace the link with a file.
• Notes on the approval. Some approvals carry a note about what the change does. Approving Create repository says the repository is made under the organization named, or under your own account when none is, and that it's private unless the agent says otherwise. Creating a repository always asks you, runs only in work you start, and can't be part of a grant held to named repositories.
• What GitHub shows before you approve. Before asking you to approve a merge, Guest Machines reads the pull request from GitHub with your account and shows it on the approval: its title and state, whether it's a draft or already merged, whether GitHub can merge it, its branch and latest commit, and the branch it merges into. Your approval covers what you saw there. If GitHub doesn't return the pull request, the merge can't be approved, and the run is told to try again later. On the run, Review Action Arguments lists the same details under Checked before you were asked, apart from the arguments the merge sends.
• No pushes to the default branch from triggered work. In work nobody watches, such as a trigger's run or a private automation's, a push (Push files or Create or update file) to the repository's default branch, the one a merge ships, is refused before you're asked and again just before it would be sent. The run is told to push to a new branch and open a pull request for you to merge. If GitHub doesn't say which branch is the default, as for a repository its search hasn't indexed yet, the push is refused too. In work you watch, such as a chat, you approve each push yourself and it isn't held to this.

If a GitHub change can't be confirmed

If Guest Machines sent a push or a merge but can't confirm that it happened, the run stops and asks you to review the outcome. It never sends the change again on its own. Choose Review Outcome on the run, then Read Current State: Guest Machines asks GitHub, with your account, what it shows now, which for a push is the branch's commit with the push's message and for a merge is the pull request. The read only shows what GitHub has; it doesn't send the change again, notify anyone or record a decision, and only you can ask for it, from your own signed-in browser. Because the change can't be confirmed exactly, your one decision is Abandon This Operation, so the run never repeats it. Finish anything that's missing in GitHub yourself.

Give an agent access

You grant access per agent and per app, and only to private agents you are the only owner of. Your Google access belongs to you alone, so a shared agent can't use it, and neither can an agent with several owners. Being a workspace admin never grants access to another person's Google account. The permissions you grant give the agent the app's tools for those operations; you don't assign Google tools on its Tools page.

Sharing an agent that has Google access asks first, then removes that access and shares the agent; the agent's page offers to turn off any Google automations that relied on it. If you leave the workspace, the agents you were the last owner of stop using your Google access, and whoever becomes their new owner can grant their own.

Your agents use your accounts only while you could start work in the workspace yourself. If you're made a viewer, or your account is locked, deactivated or removed, they stop at once, runs already working or waiting for an approval included: each later use of one of your apps is refused, the run carries on without it, and apps you signed in to yourself drop out of those runs.

1. On the app's page, under Agents, choose the agent. The same controls are on the agent's Tools page under Apps, where you choose the app first.
2. Select the operations the agent may perform and what it may use them on:
   • Google Drive: All Selected Files or individual files. Add Outputs Created in This Task to let a task keep working on files it creates.
   • Google Calendar: Allow Event Operations on or Read Availability on each selected calendar.
   • Gmail: Allow This Agent to Use This Gmail Account. Add Allow Run Files as Gmail Attachments to let the agent attach files from its own run, up to a size limit you confirm.
3. Choose Save Permissions. Remove with the app's name, such as Remove Gmail Access, withdraws what the agent was granted for that app and keeps its other apps.

Changes you haven't saved aren't lost by moving on. For any app's grant, choosing another agent or app, following a link or switching workspace first asks whether to save them, discard them or keep editing; saving switches only once the save succeeds. Closing or reloading the tab asks your browser to confirm.

Every operation you grant starts with Approve Each Use turned on, so the agent asks you each time. Clearing it lets the agent use that operation without asking. Sending email and changing calendar events always need your approval, whatever you choose here, unless you start the run with No Approvals, which asks nobody about anything. A workspace admin's tool limits come first: a tool they blocked never reaches a run, whatever you grant, and one they set to Needs approval asks even with Approve Each Use cleared.

Runs already in progress keep the permissions they started with. A new run gets the operations you added, and so does a run whose tools you change with Change Tools.

Approve emails and calendar changes

Unless the run is set to No Approvals, before an agent sends an email, saves a draft that attaches run files, creates, changes or cancels a calendar event, or answers an invitation for you, the run pauses as Awaiting Approval. The request shows exactly what will happen: the recipients, message and attached files for an email; the event, its guests and whether Google will notify them for a calendar change. Approve or deny it from the run or its chat.

Only you can approve actions on your own Google account, and only while signed in to Guest Machines in your browser. Workspace admins, other members and API keys can't approve them for you. An approval covers exactly what you reviewed; if the agent changes the message or the event, it asks again. An approved calendar change expires if it isn't made within 15 minutes.

When an agent answers an invitation, Google records your answer, and an organizer who uses Google Calendar sees it there. An organizer who uses another calendar service, such as iCloud, gets your answer only from a message Google sends them. If the approval notifies everyone, Google sends that message, and with iCloud the organizer's calendar updates within a few minutes. If it doesn't, Google may not send it, and the organizer may keep seeing your previous answer.

If Guest Machines can't confirm that an email was delivered, the run asks you how to continue and shows the message to look for: the draft, or the Message-ID you can search for in Gmail with rfc822msgid:, its subject and how many recipients it has. Check Gmail and say whether it went out; Guest Machines never sends it again on its own. An email Google refused, for example for a sending limit, isn't in question: the agent is told it wasn't sent.

Run Google work while you're away

A private automation uses your Google permissions when nobody is at the keyboard. There are four kinds:

• Private schedule. In Schedules, create a schedule and turn on Private Schedule.
• Private webhook. In Inbound Webhooks, create a webhook and turn on Private Webhook. Anyone with its URL can send events, but an event can't change the Google account, add permissions, skip your approvals or send results anywhere else. Keep the URL secret, and rotate it from the webhook's card if it leaks.
• Private API task. Open Private API Tasks under Triggers in the sidebar, then choose New API Task. The task, its fixed input, the agent and one of your API keys are set when you create it. Anyone holding that key can start that exact task, up to the hourly limit you choose, and read its results. See start an approved private API task.
• Calendar or Gmail trigger. Starts an agent when a calendar changes or new mail arrives. See start an agent from calendar changes or new mail.

Outlook, Linear, Sentry and GitHub use these same private schedules, webhooks and API tasks with the grant's Allow Unattended Use in place of Allow Private Automated Work, and Outlook, Linear and GitHub have private triggers of their own; ordinary schedules and webhooks can't use your account in them. See Outlook triggers. Slack is the workspace's account rather than yours, so ordinary triggers, schedules and webhooks can use it through Allow Unattended Use; see Slack triggers.

They all follow the same rules:

• The agent must be your own and without computer control, and its Google permissions must have Allow Private Automated Work turned on. That setting covers every Google app the agent may use on that account. Each automation starts that agent, never a workflow, because workflow steps can't use your Google access.
• A new private automation starts turned off. Choose Review and Turn On to check the task, the agent, what it may do in each Google app and the time limit for each run, then turn it on. Editing it, or changing the agent or its Google permissions, turns it off until you review it again.
• Runs happen one at a time. A run waiting for your approval holds the next one.
• Only you can see its task, results, approval requests and files.
• Its runs can't share results through other tools, control a computer or hand work to another agent. Emails and calendar changes still wait for your approval.
• Turning it off or deleting it stops any further Google actions. Events, changes and messages already waiting to start stay queued while it is off, and deleting it discards them.

Start an agent from calendar changes or new mail

Open Triggers → App Triggers:

• New Calendar Trigger runs an agent when events on one of your selected calendars are added, changed or cancelled. You choose the account, the calendar and which kinds of change count. The agent needs permission to read event details on that calendar.
• New Gmail Trigger runs an agent when new mail arrives carrying at least one label you choose (Inbox by default), optionally only from the senders or domains you list. The agent needs permission to read that Gmail account.

For Outlook Mail, Outlook Calendar and Slack, see start an agent from new mail or calendar changes and start an agent from Slack messages.

Calendar and Gmail triggers follow the private automation rules above. Each new message and each calendar change starts one run, and runs happen one at a time; repeated edits to an event that is still waiting are combined. A run is told which event or message it is about, and the agent reads it with its own permission. Email and event content is treated as information for the task, never as instructions: it can't change the account, add permissions or skip your approvals.

A trigger reacts only to what happens while it is on. Spam, trash, drafts, chats and mail your account sends never start a Gmail trigger, so the agent's own emails can't start it again, and calendar changes made by trigger runs don't start calendar triggers. A sender filter only decides which mail is relevant. From addresses can be forged, so a matching sender grants nothing.

The trigger's card shows how it is watching. Watching for changes and Watching for new mail mean Google tells Guest Machines as things happen; otherwise the card says how often it checks instead. The card also shows how many changes or messages are waiting to start. When more arrive than its queue holds, the rest wait and are added as earlier runs start. Turning the trigger off, editing it, or it pausing on its own adds those to the queue first, so they wait for your next approval with the others. View History lists what became of each one, and why a skipped one didn't run.

Edit a trigger

Editing a trigger turns it off until you review it again. What happens to the changes or messages already waiting depends on the edit, and the edit form tells you before you save:

• Wider filters keep them. Adding a label, clearing or adding senders, or adding a kind of change leaves them queued, and they start once you turn the trigger back on.
• Narrower Gmail filters skip all of them. Removing a label or narrowing the senders skips every message already waiting, even one the new filters would still match: only the message's ID is kept, so it can't be checked against the new filters, and your next approval covers only mail that matches them. The form shows how many will be skipped.
• Removing a kind of change skips only those changes. A calendar trigger skips the waiting changes of a kind it no longer runs for; the others stay queued. The form shows how many.

After you save, the confirmation says how many were skipped. Skipped changes and messages don't run, even after you turn the trigger back on.

Recover what a trigger missed

Occasionally Google can't tell Guest Machines what changed since a trigger last checked, for example after a long interruption. Because changes may have been missed, the trigger pauses and its card explains why. Review it and turn it back on. The card then offers Recover Missed Changes for a calendar trigger or Recover Missed Mail for a Gmail trigger.

Choose where the recovery starts, from the time changes may first have been missed until you turned the trigger back on, going back no more than six days. The trigger looks for what happened in that period and runs once for each change or message it hasn't already run for, oldest first. Nothing runs until the search finishes. If it finds more than one recovery can handle, nothing runs and you can try again with a later start.

• A calendar recovery reports each event once, with its overall change since the start you chose.
• A Gmail recovery matches messages by the labels they have now and your sender filter.

Time you kept the trigger turned off yourself is never recovered. Choose Dismiss if you don't need to recover.

Start an agent from Linear or GitHub events

Open Triggers → App Triggers. Under Your Linear triggers or Your GitHub triggers, choose New Linear Trigger or New GitHub Trigger. You need the app installed, and an agent of your own without computer control.

1. Name the trigger, choose the agent and the events that start it, such as Issues and Comments in Linear, or Pull Requests and Issues in GitHub, and write the task. Choose Create Trigger.
2. The trigger then shows its own Webhook URL and the steps for the vendor:
   • Linear: a workspace admin opens Settings → API → Webhooks in Linear, chooses New Webhook, pastes the URL and picks the same data changes. Linear creates a signing secret: copy it, paste it into Linear signing secret and choose Save Secret. Until then the card shows Needs Linear's secret and deliveries are refused.
   • GitHub: a repository or organization admin opens Settings → Webhooks in GitHub, chooses Add Webhook, pastes the URL as the Payload URL, chooses application/json, pastes the trigger's Secret, and selects the same individual events. The secret is shown only once; copy it before choosing Done.
3. Choose Review and Turn On to check the task and the agent, then Turn On Trigger.

Only deliveries signed with the trigger's secret start a run, one run per event, one at a time. The run receives the event's name, what happened and the vendor's payload, as information for the task, never as instructions. A trigger reacts only to events that arrive while it is on; GitHub's ping when you add a webhook starts nothing. The agent works in Linear or GitHub only through the app you granted it: when its grant has Allow Unattended Use, the run can read the issue or code the event is about. In GitHub it can also push to a branch other than the repository's default, open or update pull requests and comment, each waiting for you to approve it in the run, but never merge or create a repository; it never changes Linear. Otherwise it works from the event alone. The review lists what the run may do in each app.

Fix a failed Vercel build

Vercel reports each deployment's state on its commit, and GitHub sends it to a trigger listening for Deployment Statuses. Grant your agent GitHub held to the repository, with Allow Unattended Use, and give the trigger a task such as "If the deployment failed, find the cause and push a fix to a new branch." Each status starts a run with its state, environment, commit and the deployment's URL. The run reads the code and asks you to approve each push and pull request; it never merges, and a push to the default branch is refused before you're asked. Vercel builds a preview of the branch, and you merge the pull request yourself when it's right.

The trigger's card shows how it's doing: events received, how many are waiting to start, the last delivery, runs in progress and the last run's outcome. No deliveries yet means the vendor hasn't reached the trigger since you turned it on: check the webhook's URL, secret and events. Triggers pause automatically after repeated failures.

While a trigger's queue is full (the card shows Queue full), Guest Machines refuses the vendor's deliveries, nothing runs for them, and the card says how many it refused and when. GitHub doesn't send a refused delivery again on its own: once the queue has room, open the webhook's Recent Deliveries in GitHub and choose Redeliver on each one you want to run. A delivery sent again under the same ID, or the same signed payload sent under a new ID, runs only once.

Webhook Setup on the card shows the URL again. For Linear, paste a new secret there after rotating it in Linear. For GitHub, Replace Secret makes a new one, shown once; deliveries signed with the old one are refused until you paste the new one into the webhook. Editing a trigger turns it off until you review it again. Events already waiting stay queued, unless the edit removes an event: then every event waiting is skipped, even one of an event you kept, and the edit form shows how many before you save. View History on the card lists what became of each event. Deleting it stops its URL; remove the webhook from the vendor too. Uninstalling the app stops its triggers.

Custom apps

A custom app is a remote MCP server whose tools your agents can use. An admin adds one for the whole workspace, or you add one just for yourself.

Add your own

1. Open Apps and choose Add Custom App.
2. Enter a name and the server's HTTPS URL, and how it signs in: None, Sign in with OAuth, or Bearer token. Choose Test Connection to check that Guest Machines can reach it and to list its tools, then, under Tool access, choose which of them agents may use.
3. Choose Add App. Your app is installed for you right away and opens on its own page. For a server you sign in to, choose Sign-In Settings there, then Sign In.

Only your own private agents can use your own custom app. For a server you sign in to, only you, as its owner, can choose The owner's account, for everyone under Edit Server, which makes every run that uses it use your sign-in. If Add Custom App isn't there, an owner or admin turned off Members may add custom apps in Settings → Apps; ask them to add the app for the workspace instead.

Install one the workspace added

Custom apps the workspace added appear on Apps beside the others. Choose Install. An app that signs in as each member's own account takes you to its sign-in, then back; it can be granted only to a private agent you alone own, and runs only in work you start. An app that uses an account the workspace shares installs right away, with nothing to sign in to.

An app's page shows Sign-in required until you sign in, and Sign in again when the sign-in expired; choose Sign In or Sign In Again. Uninstall takes the app away from all your agents, and signs you out of an app that used your own account.

Grant it to an agent

On the app's page, under Agents, choose the agent; or on the agent's Tools page, under Apps, choose the app. Choose Grant with the app's name, then choose how its calls run:

• Model provider calls it: the model calls the server itself, under the server's approval setting (Ask a Person or No Approval). The agent's model must support MCP servers and that setting.
• Guest Machines calls it: Guest Machines calls only the tools you choose, from the app's last tool sync, and a person approves every call. Choose Sync Tools first if its tools haven't been synced. Schedules and webhooks that run the agent can't use these tools, because nobody is there to approve them.

The agent's edit page lists its custom apps too, under Apps, saved with the agent.

For workspace admins

Settings → Apps lists the workspace's custom apps under Custom apps.

• Add Custom App adds one for everyone. It's published, so members can install it at once. Publish does the same for a custom app you added for yourself. Publishing makes an app's saved credentials the workspace's, so only its owner can publish it: you can't publish a member's app.
• Tool Limits sets what agents in the workspace may do with each of the app's tools: Allow, Needs approval or Blocked. Each tool starts at what its server suggests (a tool that says it only reads is allowed, anything else needs approval), and that limit applies at once; the app shows how many limits you haven't confirmed yet. Review them and choose Confirm and Save. A tool the server adds later needs approval until you set it. Blocked keeps a tool out of every run. A server set to No Approval can't ask before each call, so it keeps only the tools you allow.
• Disable pauses the app for everyone, keeping their installs and agent grants; Enable restores them.
• Remove takes the app back out of the workspace. It goes back to being its owner's own app, it's uninstalled for every other member, and their agents lose it.
• Members may add custom apps decides whether members may add their own. Turning it off keeps the apps they already added.

Turn access off

• Uninstall an app from its page. Your agents lose it, its triggers stop, and what you selected for it is forgotten. Uninstalling the last Google app on an account signs that account out and revokes Google's permission.
• Choose Remove Access next to a connected file to stop agents from using it. The file itself doesn't change.
• Turn off or delete a private automation to stop its further Google actions.
• Choose Disconnect next to an account under Google accounts on the Apps page to remove it.

None of these can undo an action Guest Machines already carried out in an app, such as an email that was sent or a GitHub comment that was posted.

For workspace admins

Admins decide which apps are available in the workspace and what agents may do with each app's tools, but never get access to a member's account. For Microsoft's apps they also choose which Microsoft accounts the workspace accepts and can approve Guest Machines for their Microsoft 365 organization; see Outlook for workspace admins. Slack is connected instead of enabled; see connect Slack. Admins can see that members' private automations exist, in Members' private schedules, Members' private webhooks, Members' Calendar triggers, Members' Gmail triggers and Other members' private API tasks, and can stop or delete them. They can't see their tasks, Google permissions or results, and only the owner can turn one back on.