Handling Approvals

UpServe agents use many tools on your behalf. Most are safe to run on their own — searching the web, taking notes, organising files. A few are not: installing a new skill, hiring a new AI employee, clicking a “Pay” or “Send” button on an external site. Those land in your chat as an approval card and wait for your call. This page tells you what those cards mean and how to respond.

Why approvals exist

Agents are capable, but they cannot read your mind. UpServe draws a line between two kinds of actions:

• Safe to just do — read, search, summarise, take notes. The agent runs ahead.
• Worth a second look — anything that touches the outside world, costs money, deletes data, or submits a form. The agent pauses and shows an approval card.

This pattern is sometimes called “human in the loop” automation. It keeps the agent moving fast while making sure the high-stakes moves go through you.

Auto Execute vs Approval Required

Every tool sits in one of two modes.

• Auto Execute — the agent uses it without asking.
• Approval Required — the agent shows you a card each time before running it.

You can change this in Agent → Settings tab → Tool Approval Policy section. When you expand that section, each active tool shows a single button — either Auto Execute or Approval Required. Tapping or clicking the button flips that tool’s setting immediately.

The defaults are:

• Approval Required (default): installing a new skill, sharing an already-made file (photo, document, archive, video, and similar) as a download link, spawning a sub-agent, requesting access for the agent to call an external service with your stored credentials, and POST/PUT/DELETE external API calls.
• Auto Execute (default): web search and reading, note-taking, GET-style API lookups, team chat, creating/updating/deleting a schedule, sharing a file made directly from text you typed, and similar read-only or self-contained work.

On top of that, when an agent is driving a computer screen and reaches a risky step it spots itself — a payment confirmation, a “Send”, a consent dialog, a delete button — it asks you about that one specific click, even if the tool is otherwise set to Auto Execute.

If a tool’s approval prompt feels unnecessary, tap the button to switch it to Auto Execute. The reverse works too: a normally safe tool can be set to Approval Required when you want a closer eye on it. Either way, the setting applies to all runs including scheduled and webhook-triggered ones.

What the approval card shows

When an approval is needed, a card slides into the conversation. Read top to bottom and the information lands in the same order you’d actually weigh it:

• Which tool, and what it will do — right at the top, the tool’s name together with a one-line summary of what it’s about to do (the skill’s name and description, the web page it’s about to open, the POST request it’s about to send, and similar).
• Who made it — for anything with a publisher, like a skill install, identity info follows right below that.
• Why it’s needed — the reason the agent wrote for itself for installing or running it comes next.
• Caution notice — last, if there’s anything about this action worth flagging, it’s called out. When several things are worth mentioning at once, only the single most important one gets the coloured banner; the rest sit underneath as plain, lower-key lines. If there’s nothing to flag, this part doesn’t appear at all — it never just repeats the headline above it.
• Time left to answer — a countdown bar at the bottom. If you don’t respond in time, the card closes and the agent decides on its own whether to continue without that tool or try a different approach.

So the card is never missed just because you’ve scrolled past it, a small waiting bar stays pinned just above the message box the whole time it’s pending. It shows what’s waiting and the time left (mm:ss), and tapping Respond now jumps straight to the card.

Once you press Approve or Deny, the card stops being a screen that helps you decide and becomes a record of what you decided — so it automatically collapses to a single line showing the tool and the outcome. Tap or click that line any time to expand it back open. The one exception is a card that expired without an answer — nobody actually decided anything there, and you may still want to judge whether to retry, so it stays expanded.

Checking who published a skill

A skill-install approval card shows more than just the name and description — it also shows who made it.

• An Official UpServe skill badge — shown when UpServe itself published the skill.
• By OOO — the publisher’s name, shown when it isn’t an official skill.
• Install count — how many times this skill has been installed so far. If nobody has installed it yet, that’s called out too.
• If the name looks suspiciously close to an official skill’s name, the card carries an extra caution notice.

Use this to confirm the skill you’re about to install actually comes from a publisher you trust, and isn’t a lookalike with a similar name, before you decide whether to approve it.

Hiring an employee isn’t an approval card

Bringing on a new employee isn’t something an agent does — it’s something you do on screen. So there’s no approval card here. Press the Hire button on the Office or a team screen and a confirmation dialog appears asking exactly one thing: “Hire a new employee?” Press Confirm and the new employee exists right away.

• That dialog has no timer. Ignore it and nothing happens — nothing is ever created on its own.
• You don’t pick a name, a job, or specs here. The new employee asks about all of that themselves, in the chat that opens right after hiring.
• One press hires one employee. Need several? Press it again for each.

No approval card appears while the new hire writes their own name, role, and personality from your answers either. Instead a change card lands in the chat showing exactly what changed, with a Revert button that restores the previous content instantly if you don’t like it. See Hire Your First Employee for the full flow.

Schedules go through right away, then tell you what changed

When an agent creates, changes, or removes one of its own schedules (a task that runs automatically at a set time), that happens immediately — no approval card. Instead, a card announcing exactly what changed lands in the chat right after, so you can always see later when a schedule appeared, moved, or disappeared.

A schedule you set up yourself is different. While the agent is running on its own — waking up on schedule, doing a heartbeat self-check, and similar — it cannot touch a schedule you created. Ask for a change directly in chat (“move that reminder to 9am”) and it takes effect right away. This isn’t a case of waiting for your approval — the action is blocked outright from the start. Instead of a card and a timer, the agent simply gets told “I can’t change this on my own — I’ll bring it up next time we talk” and moves on.

Sharing a file — when it needs approval and when it doesn’t

There are two ways an agent hands you a file it produced, and they’re treated differently.

• A file built directly from text it typed — turning table data into a CSV, or notes into a Markdown document. This goes through without approval. Capped at 10MB, and it’s free.
• A file that already existed — a PDF, image, archive, or video produced while running code. This still requires approval, because the size isn’t known ahead of time and a large file can incur an extra charge.

Either way, it lands in chat as a downloadable file card. The one exception is handing a file between AI employees on the same team — that never leaves the team, so it always goes through without approval.

Approve, deny, or let it lapse

The card has two buttons.

• Approve — the agent runs the tool immediately and continues from the result.
• Deny — the agent skips the tool and looks for another way, or asks you again. If you add a short reason, the agent remembers your preference so it won’t propose the same thing again later.

You can also type a quick reply in the chat instead of clicking — this works while the card is showing and you are in a direct (non-autonomous) conversation. Words recognised as approval: “yes”, “ok”, “approve”, “allow”, “confirm”. Words recognised as denial: “no”, “deny”, “cancel”, “reject”, “disallow”. Anything else — or an ambiguous phrase — defaults to denial for safety.

If you ignore the card, the timer eventually runs out and the card closes itself. The agent learns “the user didn’t respond” and moves on without that tool, or revisits it next time. A short “Agent decided” line then appears below the card, showing what the agent actually did right after it expired — the name of a different tool it used instead, the first sentence of the text reply it gave, or “Stopped without proceeding” if it made no decision at all.

Answering a question can actually make something happen

While an agent is working, it sometimes asks you something and shows tappable options. Some of those options don’t just record your answer — picking one triggers a real action right away. For example:

• “Cancel this task, or keep going?” → picking Cancel actually cancels that task.
• “Mark this as done?” → picking it actually marks the task complete.
• “Pause this schedule for a while?” → picking Pause actually pauses the schedule, and picking “turn it back on” later actually resumes it.

If an option is hard to undo (cancelling or deleting something, for instance), tapping it doesn’t fire right away — a “are you sure?” confirmation pops up first. Only confirming there actually carries it out, so a quick, accidental tap can’t trigger something you can’t take back.

Choosing an auto-approve scope

Above the Approve/Deny buttons, an approval card also lets you pick an auto-approve scope. While you’re approving this one request, you can also decide how much further auto-approval to grant for the same action going forward.

• Just once (default) — approves only this request. The same action asks again next time.
• Next 5 — the same action is auto-approved up to 5 more times without asking. Once those are used up, it asks again.
• For this task — auto-approves the same action for as long as the current task (a piece of work the agent opened) is running. It’s cleared automatically once that task finishes.
• Always — keeps auto-approving going forward. If the action goes unused for a while, though, it expires on its own and asks again next time. A few especially high-risk tools don’t offer this option at all, for safety.

Whichever scope you pick, it only ever covers the same action you just approved — approving one button on a page doesn’t extend to a different button or a different page, and approving one external API request only covers requests using the same method to the same address.

Cancelling an auto-approval you already granted

Whenever you have an active auto-approval, a banner appears at the top of the chat showing what’s currently being auto-approved. Each row on the banner has two buttons.

• Revoke — actually cancels the auto-approval. The next time that action comes up, you’ll be asked again.
• Hide (eye icon) — collapses just that row from the banner’s display. The auto-approval itself stays active — this only keeps the chat from being cluttered with approval notices.

An auto-approval you turn on while chatting directly only applies to that same kind of direct conversation — it does not carry over to scheduled or heartbeat runs that happen without you present, and only kicks back in the next time you’re chatting directly again. Conversely, an auto-approval granted in a context other than direct chat (a scheduled run, for example) shows a small badge on its banner row naming that context, so you can tell how far the current auto-approval actually reaches.

Even if you’ve hidden every row, you can see and manage everything that’s currently auto-approved from Agent → Settings tab → Active auto-approvals. That list always shows every grant, including ones hidden from the banner, each with its own Revoke button.

Approving the same thing repeatedly gets you a rule suggestion

If you keep approving the same tool and never deny it, you’ll get a notification asking “want to auto-approve this going forward?” Tap it and you land on the agent’s Settings tab, where the Suggested approval rules section lets you tap Turn into a rule to actually create one. Once created, that tool goes through without asking for the next 50 calls; after that it asks again.

A handful of higher-risk tools (code execution, skill installs, requests for access to external services, and similar) never get this suggestion no matter how often you approve them — those stay on individual confirmation by design.

Approvals during autonomous runs

Agents don’t only work while you’re chatting. They can wake up on schedule, run a heartbeat self-check, or be triggered by an incoming webhook, and the same approval may pop up in the middle of that background work. When that happens:

• The card lands in the agent’s chat as usual.
• If you have push notifications on, you’ll get an “Approval needed” alert.
• For schedule, heartbeat, and webhook runs, the wait time is extended automatically, because those runs assume you can’t reply right away. Push notifications are also sent whenever the timeout reaches 10 minutes or more — even on a regular chat session.
• If the approval or question comes from a Workstream — a separate piece of work the agent opened alongside your main conversation — it resolves automatically faster than one in the main conversation. This keeps a single Workstream from holding up the main conversation while it waits for you. The one exception is a question where the agent hands the screen over to you for something it can’t do itself (signing in, entering a verification code, and similar) — that waits for you to actually open the Workstream, with no shortened timer. See Workstreams to learn what a Workstream is.

To make sure you don’t miss these, enable push notifications in Notification Settings .

Common scenarios

1) Installing a new skill from Explore in the Skills tab

When the agent decides “this skill would help with my task,” it calls the install tool. The card shows the skill’s name and description plus a short reason for needing it. If you trust the package, Approve; otherwise Deny with a note like “use a different approach this time.”

2) Running code or issuing a command on its machine

When an agent needs to run something directly — converting files, crunching data, calling an external tool — the card shows what it’s about to run and why. Approve if it reads sensibly, or Deny and ask for a different approach.

Hiring an employee isn’t on this list — hiring is a button you press, not a tool an agent calls (see “Hiring an employee isn’t an approval card” above).

3) Reaching a payment or “Send” step on an external site

When an agent is browsing the web and reaches a high-impact button — Post, Pay, Send, Delete, Agree — it asks before clicking. Read the reason on the card, then decide.

4) Exporting the agent’s own work as a reusable skill

When the agent packages what it built into a shareable skill, a skill review card appears — distinct from a regular approval card. On that screen you can edit the name, description, and file list before confirming. Confirming does not publish the skill immediately.

5) Reaching an external service while running code

When the agent needs to call an external service without ever pulling your stored password or connected account into its code-execution environment, it requests a safe pass-through where the credential is injected on the server side instead. You’ll see an “Authorize External API Access” card summarizing exactly which account, which address, and what kind of request (read, create, change, and similar) it would be allowed to send. Once approved, that pass-through stays open, so requests within the same scope won’t ask again — read the card’s summary carefully before approving.

6) The agent proposes changing its own specs

When a task keeps failing from running out of memory, or the agent notices it hasn’t needed its current specs for a while, it shows a card proposing a spec (CPU/memory) change. The card shows the current and proposed specs together with how many SU per minute go up or down — a downgrade proposal also shows the maximum possible savings over a month. Approving it doesn’t take effect right away; the new specs apply starting the next time this agent’s sandbox starts up.

How the web browser decides what to approve

When an agent uses the web browser tool — opening pages, clicking buttons, typing into fields — the approval decision is based on what that action actually does to the page, not just the action type. The same “click” that opens a menu is auto-approved; the one that posts a message needs your sign-off.

Always auto-approved

These actions observe the page without changing anything and always proceed without a card:

• Snapshots, screenshots, scroll, hover, back/forward navigation
• Checking the current URL, page title, or whether a specific element is present
• Waiting for content to load

Always requires approval

The following are irreversible or high-stakes, so the agent always asks first:

• Clicking a button that the agent itself flags as an irreversible action — posting, sending, paying, deleting, unsubscribing, and similar. What the agent is about to do is shown in the approval card’s Intent field
• Submitting a sign-in or sign-up form — judged structurally, not by button label. A form that submits to a different site (cross-origin) always requires approval; a typical same-site login or sign-up form only requires approval when the agent itself flags that submit click as irreversible
• Typing into a password field, card-number field, or one-time code (2FA) field
• Clicking a submit button whose form posts to a different website
• Any click or input inside a third-party widget — payment dialogs, OAuth pop-ups, and similar
• Uploading a file

Context-dependent actions

A plain text input can go either way. Typing into a search box is auto-approved; typing into a field inside a login form requires approval. The agent looks at the role and context of the target element to decide.

If the agent clicks or types on a stale reference with no matching element information, that alone does not trigger an approval card — a stale reference is almost always just a side effect of the page having just changed, so the action auto-proceeds; if the reference is genuinely no longer valid, the tool call errors out and asks for a fresh snapshot instead. An approval card only appears when the agent itself flags that specific action as irreversible.

What “Next 5” actually counts

If you pick “Next 5” in Choosing an auto-approve scope, those 5 uses only count meaningful actions: the kind that warrant approval in the first place. Snapshots, URL checks, and other automatically-passing reads do not consume from that count. You will not burn through the 5 faster than expected.

---

Advanced

This section is for users who want to tune approval policy per tool or understand what may stall a background run.

How tools are classified for approval

There are two paths that generate an approval card. A couple of other actions use a different kind of card instead.

Always requires approval (static classification)

These tools trigger an approval card on every call:

• skill_install — install a skill, either one you picked from Explore in the Skills tab or one from a public GitHub repository you pointed the agent at (no auto-approve scope is offered for either source)
• sub_spawn — spawn a one-shot sub-agent
• webapp_grant_request — request access for an agent-built webapp to call an external service
• egress_grant_request — request access for code execution (bash) to call an external service
• sandbox_tier_change_request — ask to move the agent’s own sandbox to a higher- or lower-performance tier

Conditionally requires approval (dynamic classification)

• External API calls (http_request): POST, PUT, PATCH, DELETE methods require approval. GET/HEAD/OPTIONS are auto-approved.
• Code execution (bash): a command that looks like it’s sending data out — a curl/wget-style request, for example — requires approval. The exception is a request that only uses a pass-through you already approved (the egress_grant_request grant from the static list above); that goes through automatically.
• File sharing (file_share): a file up to 10MB built inline from text (content) goes through without approval (since 2026-08-14) — that path never hands the signed download address back to the agent, only attaches it to your chat, so there’s no way for the link to leak. Video is the one exception: even built inline from content, it still requires approval. Uploading a file that already exists (path, a sandbox binary) still requires approval, since its real size isn’t known ahead of time. Handing a file off inside the same team (visibility="team") never leaves the team, so it always auto-proceeds.
• Computer-screen control (computer_use): approval isn’t decided by action type. Only system-destroying command patterns are blocked outright; everything else — clicks, typing, dragging, scrolling, and similar — auto-executes by default. An approval card appears only when the agent itself looks at the screen and judges the action irreversible (a payment, a delete, and similar), the same self-classification described above.
• Web browser (browser): see the “How the web browser decides what to approve” section above.

Tools that run without approval and just leave a card behind

• schedule_create / schedule_update / schedule_delete — creating, changing, and removing schedules (no approval since 2026-08-14). A card announcing exactly what changed lands in chat right after the call runs. A schedule you set up yourself is protected during autonomous runs — schedule_update/schedule_delete calls against it are rejected at the code level, so a deterministic guard now stands where the approval card used to. The built-in heartbeat and sensor-watch schedules are protected by separate rules and can’t be edited or removed through these two tools at all.

Cards that aren’t approval cards

• A new hire writing their own profile — while a newly hired employee sets their own name, role, and personality during onboarding, you get a change card instead of an approval card (see “Hiring an employee isn’t an approval card” above). It doesn’t wait for approval; it shows what changed and offers a Revert button. There’s no timer, so you can undo it whenever.
• skill_export — when the agent packages its work into a skill. This one doesn’t wait for approval at all. The tool runs immediately, creates a private draft, and a review card appears in chat right after. There’s no expiry timer — open the card whenever you like to inspect the name, description, and file list, edit them, and decide whether to publish. Nothing is visible to anyone else until you confirm.

What a question option’s actions actually do

As described in “Answering a question can actually make something happen” above, each option on an ask_user question card can carry up to 4 actions that fire when it’s picked. The supported actions are: mark a task complete, cancel a task, create a new task, defer a task, pause a schedule, resume a schedule, and clear a blocking condition. An option flagged as irreversible shows a confirmation dialog before it fires instead of acting immediately. If the target (a task or schedule) has already changed state between when the question appeared and when you actually answer, that action is safely skipped. For state-flipping actions — completing, cancelling, pausing, or resuming — a mismatch also skips every action still queued after it in that option; for the others (creating, deferring, clearing a blocking condition), only that one action is skipped and the rest still run.

When the auto-approve rule suggestion fires

If you keep approving the same tool over the last 30 days without ever denying it, a once-daily check picks it up and sends a suggestion notification. Code execution (bash), skill installs (skill_install and the GitHub-repository install path), webapp_grant_request, and egress_grant_request are always excluded from this suggestion, regardless of how often they’re approved — their risk stays too high. The same (agent, tool) pair only gets suggested once every 14 days, and denying it once resets the trust count, so it has to build back up before it’s suggested again. Tapping the notification takes you to the agent’s suggested-rules screen; accepting there issues a rule that auto-approves the next 50 calls to that tool.

Actions blocked without a card

Some actions are rejected immediately — the agent gets a “blocked by policy” result with no user prompt. Common cases:

• A code execution command containing system-destructive patterns such as forced deletion of root or home paths, fork bombs, download-pipe-to-execute chains, filesystem formatting, or direct block-device writes.
• An action that is explicitly set to blocked in the agent’s configuration.

An agent that hits this block does not retry the blocked command; it looks for an alternative approach.

Per-tool approval toggle

In Agent → Settings tab → Tool Approval Policy, each tool has a single button that controls its approval behaviour.

• Auto Execute: all future calls go through without a card, including scheduled and webhook-triggered runs.
• Approval Required: an approval card appears every time the tool is called.

How the toggle works under the hood adapts to the tool’s built-in risk level. For a tool that is “Approval Required” by default (like spawning a sub-agent or a mutating external API call), switching to “Auto Execute” permanently grants that tool automatic pass-through. For a tool that is “Auto Execute” by default, switching to “Approval Required” escalates it so you are always prompted.

A few especially high-risk tools are the exception: installing a new skill, and requesting access for the agent to call an external service with your stored credentials (webapp or code-execution egress) keep this button locked on “Approval Required” — tapping it does nothing. Hiring a new AI employee isn’t part of this list at all — it’s a button you press on screen, not a tool an agent calls (see “Hiring an employee isn’t an approval card” above), so there’s nothing here to toggle for it.

All per-tool approval settings live in that one button next to each tool — there is no separate panel to check.

The auto-approve scope picker on an approval card is separate from this toggle. “Next N” is a temporary grant consumed by call count, “For this task” is cleared once the current task finishes, and “Always” auto-expires if left unused for a while. All three can be cancelled at any time from the Revoke button on the banner at the top of the chat, or from Active auto-approvals in the Settings tab. The bash tool loses only the “Always” scope, for safety — the other three scopes (Just once / Next 5 / For this task) remain available. skill_install, webapp_grant_request, and egress_grant_request carry even higher risk, so no scope picker appears for them at all — every call needs its own one-off approval.

Hiding a row on the banner with the eye icon only applies to the device/browser you’re using — the row can reappear if you open the same agent elsewhere. Active auto-approvals in the Settings tab always lists every grant on every device, regardless of what’s hidden from the banner.

What the timeout outcome line shows

When an approval or question card expires unanswered, the first decision the agent actually makes right after that is summarized (rule-based, no extra cost) and attached back to the original card. It’s always one of three kinds:

• It proceeded by calling a different tool — that tool’s name (up to 3, plus “and N more” beyond that).
• It wrapped up with a text reply to you — the first sentence of that reply (up to 180 characters).
• It made no decision at all and the turn simply ended — “Stopped without proceeding”.

The result is matched back to the exact original card by call id (not “the most recent expired card”), so it can never land on the wrong card even if another one appeared in between.

Web browser approval policy in detail

How element risk is classified

Click, type, fill, and select actions are classified using element information collected during the most recent snapshot — essentially, what that action would actually do (navigating somewhere versus submitting or sending data, for example).

When the most recent snapshot has no information for that element (a stale snapshot or an expired reference), the mutation action auto-approves by default. This was changed specifically to stop a flood of false-positive approvals whenever a reference went stale right after the page changed. If the reference is genuinely invalid, the tool call errors out at execution time and asks for a fresh snapshot. Cases that do warrant approval — password fields, third-party form submissions, and similar — are still caught by the agent’s own irreversibility flag (the Intent field).

Key press actions (Enter, Tab, Escape, and similar) dispatch a global keyboard event to whatever element currently has focus and carry no element reference, so the element information classification above does not apply. They auto-approve by default. An approval card appears only when the agent explicitly marks the action as dangerous — for example, when it knows pressing Enter will publish or submit a form.

Agent self-classification

Click and type actions are not classified by label-keyword matching. On sites like X, Reddit, and Slack, action verbs (“Post”, “Reply”, “Like”) appear as card-section labels, comment-icon accessibility labels, and input placeholders — keyword-based blocking produced false positives where comment-icon clicks and normal textarea typing were escalated even though the irreversible step was several clicks away.

Instead, the agent directly marks any call it believes to be irreversible (posting, sending, deleting, paying, unsubscribing, and similar) and includes a short intent description. That signal raises the call to the approval level and surfaces the agent’s stated intent in the approval card’s Intent field. Self-classification is escalation-only — it can never lower the deterministic rules described above.

Auth-related form submissions

The current code does not read label words like “Sign in” or “Create account” at all — an earlier label-matching rule existed but was removed because it couldn’t reliably cover every site’s wording. The structural rule that fires deterministically is only the form submitting to a different site (cross-origin); a same-site login form only requires approval when the agent itself flags that submit click as an irreversible action.

Sensitive autocomplete values

Write actions targeting fields typed as card number, security code, card expiry, one-time code (2FA), or password always require approval, based on the field’s autocomplete type.

Script execution actions

The browser’s script execution action is checked before it runs — if the script could change the page or send data out, it requires approval. A script that only reads information back auto-approves.

The read-only structured query action — which can retrieve the current URL, page title, scroll position, and whether specific elements are present — always auto-approves without script analysis.

Limits of agent self-classification

An agent that marks a call as dangerous will trigger an approval card. This signal is escalation-only — if a call is already required to have approval based on the deterministic rules, the agent cannot override that downward to auto-execute. Marking an inherently safe action (snapshot, scroll, read-only query) as dangerous is silently ignored by the over-mark guard.

What happens after you deny

When you deny, the agent receives:

• A clear signal that the user explicitly declined.
• The reason you typed (if any).
• An instruction not to repeat the same suggestion.

The agent saves your preference as a “feedback” memory note, then either tries an alternative or asks you a clarifying question. The net effect is that the same proposal won’t keep coming back in future runs.

How long the agent waits

When a tool is set to Approval Required, the default wait time depends on the tool type:

• Code execution — about 5 minutes
• Driving a computer screen — about 10 minutes
• Installing a skill — up to 1 hour (so you can read the skill’s contents)
• Everything else — the default value

For schedule and heartbeat runs, these times are automatically multiplied by 4. For webhook runs, they are multiplied by 2. A single approval will never wait more than 24 hours total.

Approvals and questions raised inside a Workstream (a separate piece of work the agent opened alongside the main conversation) get one more cap on top of the above — 10 minutes for an approval, 15 minutes for a question — even if a schedule or heartbeat multiplier would otherwise extend it further. This keeps one Workstream from blocking the main conversation for long while it waits on you. The one exception: a question where the agent hands screen control over to you (sign-in, a verification code, and similar) skips this cap and keeps its original wait time, since actually opening the Workstream and acting on it takes real time. These numbers may be tuned as the feature stabilizes. See Workstreams for the concept.

Approvals in Shared (Snapshot) mode

When you open an agent via a share link (/share/...) or embed (/embed/...), the external session runs against a fixed allowlist of safe tools. Tools that require approval — like skill installs — are not available in that session at all, so no card appears for them.

However, tools that are in the allowlist can still generate dynamic approval cards in some circumstances (for example, a browser action that reaches a high-risk element). External visitors may see those cards, but their responses have no lasting effect on your agent’s settings. When you use the same agent directly as its owner, the full approval policy applies as normal.

Related pages

• Core Concepts — balancing autonomy with human checks
• Build Your First Agent — default tools and scheduling
• Workstreams — what a Workstream is and how it differs from the main conversation