MultiOn Chrome extension: how do I run actions locally in the user’s own browser session for authenticated sites?

Most teams hit the same wall with authenticated sites: your app needs to “do things” in a user’s account, but you can’t (and shouldn’t) ship your own fragile browser automation stack. MultiOn’s Chrome extension gives you a different path: run actions locally, inside the user’s existing, logged-in browser session, driven by the same agent logic that powers the Agent API.

This guide walks through how to use the MultiOn Chrome extension to run actions in a user’s own browser session on authenticated sites—without building and maintaining Playwright/Selenium test farms.

When to use the MultiOn Chrome extension vs Agent API

Think in terms of where the browser session lives:

Agent API (V1 Beta)
- Browser runs remotely in MultiOn’s secure environment
- You authenticate via X_MULTION_API_KEY
- Ideal for backend workflows, parallel agents, and server-side orchestration
- Great for flows like “order on Amazon” or “post on X” without touching the user’s local browser
Chrome Browser Extension
- Browser is the user’s own Chrome profile
- Uses their existing cookies, logins, 2FA, and extensions
- Ideal when:
  - The user is already logged into an app you don’t want to re-authenticate remotely
  - Bot protection or device fingerprinting is tied to the user’s machine
  - You want visible, in-context actions (the user can watch the agent operate)

For authenticated, user-specific workflows—like “update my shipping address in my Amazon account” or “post this draft to my team’s Jira”—the extension is usually the right tool.

How the Chrome extension runs actions locally

Conceptual model:

User installs the MultiOn Chrome extension.
You or the user issue a natural-language instruction in the browser context (via the extension UI or a trigger in your app).
The extension coordinates with MultiOn’s agent stack to interpret intent.
Actions execute in the current tab and session:
- Clicks, form fills, navigation, scrolling
- All against the already-authenticated site, using the user’s cookies
Results are returned in-page (e.g., status, confirmation, extracted data) or reflected directly in the UI (e.g., order placed, form submitted).

The key difference from server-side automation: you’re not recreating login flows or fighting bot protection on headless Chrome. You’re riding on the user’s real session.

Setup: getting the MultiOn Chrome extension into your stack

From an engineering standpoint, you have two primary integration patterns: “user-driven” and “app-triggered.”

1. User-driven install and usage

Use this when:

You’re shipping a product that recommends MultiOn but doesn’t need tight programmatic control.
You’re dogfooding MultiOn to explore what’s possible on authenticated sites your team uses daily.

Steps:

Install the extension
- Go to the Chrome Web Store and install the MultiOn extension.
- Pin it to the toolbar for easier access.
Log into the target site
- Example: open https://www.amazon.com and sign in as usual.
- MultiOn will reuse this session—no need to rebuild auth flows.
Open the MultiOn extension
- Click the extension icon in Chrome.
- You’ll see a prompt area for instructions.
Describe the task in natural language
- Example commerce tasks:
  - “Buy my latest saved item from my Lululemon wishlist”
  - “Reorder my last 3 Amazon purchases and ship to my default address”
- Example productivity tasks:
  - “Create a new task in this Asana project with title ‘Refactor payment API’ due next Friday”
  - “Post a message in this Slack channel summarizing the last 5 PRs from GitHub”
Let the agent operate
- The agent will navigate, click, and fill forms in the current tab.
- Because it’s your local session, it inherits:
  - Logged-in state
  - 2FA-completed cookies
  - Your local extensions (ad blockers, password managers, etc.)

2. App-triggered usage (recommended for product teams)

Use this when:

You have a web product and want to trigger MultiOn actions inside the user’s session.
You want to offer “Do this for me” buttons instead of asking users to type prompts manually.

High-level pattern:

Require or recommend the MultiOn Chrome extension.
- On relevant pages, detect if the extension is installed:
  - If yes: show “Run with MultiOn.”
  - If no: show “Install MultiOn to automate this step” with a link.

Emit a structured intent from your app.

When the user clicks your button, send a message that the extension can consume.
Example: a small client script that window.postMessage’s a payload like:

window.postMessage(
  {
    source: 'my-app',
    type: 'MULTION_INTENT',
    task: 'update-shipping-address',
    params: {
      addressLine1: '123 Market Street',
      city: 'San Francisco',
      state: 'CA',
      zip: '94103'
    }
  },
  '*'
);

Let the MultiOn extension map that intent to an agent instruction.
- The extension can translate your structured payload into a natural-language cmd internally (e.g., “Update the shipping address on this site to 123 Market Street, San Francisco, CA 94103”).
- The agent executes the workflow directly in the user’s current tab and session.
Return feedback to the user.
- Surface success/failure in your UI:
  - “Shipping address successfully updated.”
  - “We couldn’t find the address settings page—click here to open it manually.”

This pattern keeps you out of the browser automation business. You emit intent; MultiOn handles the clicks.

Why local browser sessions matter for authenticated sites

As someone who spent years babysitting Playwright/Selenium suites, here’s why the Chrome extension model is compelling for logged-in, bot-protected apps:

1. You reuse the user’s real authentication

No more:

Explicit scripting of login flows for each site
Managing OTP/2FA interception
Storing passwords or rotation logic

The extension simply operates on top of the session the user already established.

2. Bot protection behaves like a human user

Remote automation often triggers:

Browser fingerprinting blocks
Captchas tied to suspicious IP ranges
“ERR_BLOCKED_BY_CLIENT” scenarios when extensions or ad blockers interfere in unexpected ways

With the extension:

The agent acts as the user, in their actual browser, using the same IP, cookies, and installed extensions.
If something is blocked, the user can see it and adjust (e.g., temporarily disable a blocking extension).

3. No fragile selectors shipped in your codebase

Traditional flow:

You hardcode selectors for login, buttons, and form fields.
The site changes one attribute, and your automation pipeline collapses.

With MultiOn:

The agent interprets high-level instructions in context.
You don’t maintain selector maps across dozens of third-party web UIs.
You focus on intent (“checkout this item”) instead of click coordinates.

Example: running a “buy my latest saved item” flow locally

Let’s walk through a concrete example modeled after commerce flows like “Buy my latest saved item from my Lululemon wishlist.”

Step 1: User context

User is logged into Lululemon in Chrome.
They have items saved in their wishlist.
MultiOn extension is installed and enabled.

Step 2: Instruction

From the extension prompt:

“Buy my latest saved item from my Lululemon wishlist.”

Step 3: Agent actions in the local session

In the user’s own tab:

Navigate to the wishlist page (if not already there).
Identify the most recently saved item.
Add that item to the cart.
Proceed to checkout:
- Confirm shipping address (or use default).
- Select payment method (reusing saved cards).
- Place the order.

All of this happens inside the user’s authenticated session. No credentials cross into your backend. No Playwright scripts. No remote headless browser.

Step 4: Result

The user sees the order confirmation in their browser.
You can optionally ask the agent to surface structured details:
- Item name
- Price
- Order number
- Estimated delivery date

If you later decide you want the same flow in a backend context, you can port it to the Agent API (V1 Beta) and let the remote agent handle it, but the extension gives you a no-infrastructure way to prove out the experience first.

Handling common edge cases in local sessions

Even with local execution, you’ll run into operational quirks. Here’s how to think about them:

1. Page blocked by an extension (ERR_BLOCKED_BY_CLIENT)

Symptoms:

The page fails to load.
Chrome shows “This page has been blocked by an extension (ERR_BLOCKED_BY_CLIENT).”

Impact:

MultiOn can’t complete the task because the website itself is blocked.

Mitigation:

Instruct users to:
- Temporarily disable the blocking extension for that site.
- Whitelist the domain in their ad blocker or privacy tool.
- Reload the page and rerun the task.

From a product POV, you can show guidance like:

“If the page is blocked, disable any ad blockers for this site and try again. MultiOn needs the page to render to take actions.”

2. User logs out mid-workflow

If the user’s session expires or they manually log out:

The agent will likely be redirected to a login page.
Actions targeting deep pages will fail or misbehave.

Mitigation:

Remind users: “Stay logged in while MultiOn is operating on this site.”
Consider having the agent detect login pages and prompt the user to log back in before continuing.

3. Dynamic, JavaScript-heavy UIs

For authenticated web apps with heavy JS (e.g., dashboards, SPAs):

The agent still interacts at the visual/DOM level.
Because it runs in the real browser, it inherits:
- All JS execution
- Client-side routing
- Lazy-loaded components

If you also need structured data from these pages, pair the Chrome extension with MultiOn’s Retrieve capabilities (via backend or future local hooks) to produce:

JSON arrays of objects describing things like:
- Orders
- Tickets
- Products
- Messages

Working alongside the Agent API and Retrieve

MultiOn’s Chrome extension is one surface. The others are:

Agent API (V1 Beta): POST https://api.multion.ai/v1/web/browse
- You send a cmd + url with X_MULTION_API_KEY.
- MultiOn spins up a secure remote session, executes actions, and returns state.
- Use session_id to maintain continuity across calls (e.g., add to cart → checkout).
Retrieve:
- Explicitly designed to turn dynamic pages into JSON arrays of objects.
- Use controls like:
  - renderJs – ensure JavaScript-heavy content is fully rendered.
  - scrollToBottom – handle infinite scroll/lazy loading.
  - maxItems – cap extraction size.

Typical hybrid pattern:

Use the Chrome extension to prototype how the agent should behave in a user’s authenticated session.
Once the flow is stable, decide:
- Keep it local if it must operate on the user’s actual browser state (e.g., company-specific SSO).
- Move to Agent API if you want backend, parallel execution at scale.
Use Retrieve when you also need structured outputs from those authenticated pages.

Implementation checklist for product teams

If you want to add “run actions locally in the user’s own browser session” to your app using the MultiOn Chrome extension, use this as a quick checklist:

Decide which flows belong in the user’s browser.
- Examples:
  - “Post this update to my X account.”
  - “Sync this project to my Asana workspace.”
  - “Add this item to my Amazon cart and checkout.”
Add extension-aware UI.
- Detect the extension and show a “Run with MultiOn” entry point.
- Provide a clear fallback/CTA to install the extension.
Define structured intents.
- Map buttons to specific task types and parameters.
- Avoid raw prompt strings in your app; instead, send consistent schema the extension can map to prompts.
Document edge cases for your users.
- “Stay logged in while MultiOn is running.”
- “Disable blocking extensions if the page doesn’t load.”
- “We don’t store your credentials; everything runs in your own browser.”
Plan for scale with the Agent API.
- For heavier workflows, migrate or augment with:
  - POST https://api.multion.ai/v1/web/browse
  - session_id for Sessions + Step mode
  - Retrieve for JSON outputs
- Expect standard API behaviors, including explicit error states (e.g., “402 Payment Required” when you hit billing limits).

Final thoughts

Running actions locally in the user’s own browser session is often the simplest way to automate authenticated sites without inheriting a full browser automation stack. MultiOn’s Chrome extension lets you do exactly that:

Intent in (from the extension or your app).
Actions executed in the user’s real, logged-in browser.
Optional structured outputs via MultiOn’s broader platform.

If you’re currently nursing Playwright or Selenium flows that constantly break on login-heavy, bot-protected sites, the extension gives you a cleaner mental model: let your users keep owning their sessions; let MultiOn own the clicks.

Get Started