Browser profiles

Browser Pool stores platform accounts and general browser profiles for publishing, workflow automation, URL imports and agents. Each profile has its own sign-in state, site storage and proxy configuration. Profile permissions control which identity can be used.

Two kinds of profile#

• Publishing accounts are bound to a platform (TikTok, YouTube, Douyin, Bilibili, Xiaohongshu, WeChat Channels). The publishing matrix picks from these, and the platform binding is what lets Mosael know which upload flow to drive.
• General profiles are for any other site. A workflow's RPA nodes and the agent's browser tools use them.

Both are created the same way: New profile, then sign in inside the embedded browser window exactly as you would in Chrome. Mosael never sees or stores your password — what it keeps is the session the site handed back.

General profiles: a browser that keeps its state#

A general profile card's main button is Open, and it takes you back to where you left off: if the embedded view is still alive it is shown as it is; after a restart, when the view is gone, it opens the address recorded when the view was last closed. Only the very first open asks which site to go to. To go somewhere else, use Open another site (the pencil icon) — the only entry that navigates the page away.

Sites you sign into here stay signed in the next time you open the profile, and when workflows or the agent use it. Opening it by hand also updates the card's "Used …" line, with the host of the site you were last on.

General profile cards carry no sign-in badge: a profile can hold any site, and Mosael cannot tell whether you are signed into an arbitrary one, so it does not guess.

Once it's open: the browser session#

After Open, the whole window is this profile's browser (desktop app only). The top bar has back, forward, reload and the address bar on the left, and the page tools and Back to Mosael on the right; the column on the left is the session's page list. Back to Mosael tucks the browser away while the page stays loaded in the background; when you're not typing in the page, pressing Esc twice also brings you back (with the focus in a text field on the page, Esc belongs to the page — closing a suggestion list or leaving an editor often takes a double Esc).

Keyboard focus follows you. Once it opens, the focus is in the page, so you can type or scroll right away; after clicking back, forward or reload in the top bar with the mouse, or switching, opening or closing a page in the page list, the keyboard goes back to the page, as it does after pressing Enter or Esc in the address bar. Moving through the top bar with the keyboard keeps the focus there. When the browser tucks away, the focus returns to the button you had before it opened.

A dialog open underneath stays open. Arriving from Open in workbench in the workflow library, say: clicking the top bar, the page list or the address bar, or pressing Esc in the address bar, leaves the workflow library open underneath, and Back to Mosael returns you to the same workflow in it.

Page tools in the top bar#

The five buttons are icons only: hover for the name and a line of explanation (drawn over the page, below the button, without covering the address bar). A button you can't use is greyed out and its hint gives the name, the explanation and why it can't be used (no page is open yet, the previous action hasn't finished; while a page is still loading, finding videos, finding images and reading the text wait until it has loaded). They all act on the page in front of you, signed in as this profile.

Tool	What it does
Screenshot	Choose Visible area, Full page or Select area. A full page is drawn in one go, so a sticky header doesn't repeat on every screen; beyond 15,000 pixels only the first part is taken and you are told so. For a selection, drag a box over a frozen frame; Esc cancels. The screenshot goes to the media library with the page URL, page title and capture time
Download video	Opens a column on the right listing the videos on this page. A platform page (Bilibili, Douyin, Xiaohongshu, YouTube and the like) is one card that goes through import from link for the whole page; an ordinary page lists the video files, HLS streams and DASH streams found in its players and network traffic. Downloads run in the background with progress and cancel in the column and in the task center, and finish in the media library with the page they came from. DRM-protected or encrypted streams are marked as protected and can't be downloaded; Mosael doesn't try to get around that
Collect images	Lists the images on the page that are big enough (icons and tracking pixels are filtered out); tick the ones you want and Save to the library, each with its page and its own image address. Sites that block hotlinking still work — images are fetched as this profile, from the page they're on
Save as note	Whole article or Selected text. The whole article is read from the page as you see it right now (text you only see signed in included), keeping the main article and dropping navigation and sidebars; the note opens with a source line, and its sources record the URL and page title. With nothing selected you are told so instead of getting an empty note
Start from this page	Viral breakdown, Account health check, Comment insights: builds the official template (or opens the one you already built), fills this page's link into the start node and sets the data source to the built-in browser using this very profile; one that a scheduled task is bound to is left alone and a new one is built. It doesn't press Run for you — the browser tucks away on that workflow, ready to check and run. Ask the agent starts a new conversation with "Take a look at this page for me:", the page title and the link in the input, without sending it

Confirmations appear in the top bar too, such as "Saved to the library · View" or "Saved as a note · Open"; one click tucks the browser away and opens the result.

Downloads on a page go straight to the media library#

Clicking a download link in a browser session no longer brings up the system save dialog: the file goes straight into the current workspace's media library with its download URL, the page it was on and the time, and the top bar says Saved to the library with View to jump there. Downloads that finish after you tucked the browser away are saved as well. Types the library doesn't take (installers, archives and so on) and files over 2 GB stop right away with the reason.

The page list#

A browser session can have several pages open; the column on the left lists them with the site icon and title, the address on hover and the current page highlighted. Click a page to switch to it, close a page (except the last one), drag to reorder; New page at the top opens an address or search words on Enter. Links a page opens in a new window (target=_blank, window.open) no longer pop up a small window — they join this list and become the current page; third-party sign-in pop-ups still call back, close themselves when done and return you to the page you were on. A session holds at most 10 pages at once, and tells you to close a few first.

The list can collapse to a strip of icons, remembered on this device. While collapsed, resting the pointer on the strip expands the list over the page for a moment, with every page's title and address; move away and it tucks back, without pushing the page around. To keep it open, choose Keep the page list expanded in the expanded list. Collapsing, expanding and peeking all take a short transition during which the page holds still for a moment (about 0.2 seconds) and slides with the list instead of jumping; with reduced motion turned on there is no transition. A truncated title in the list shows in full on hover, in a hint drawn to the right, over the page.

The floating browser workflows and the agent use#

When a workflow or the agent opens a browser, it floats as a card in the bottom-right corner of the window so you can watch it work:

• The title says whose it is: one a workflow opened reads "Workflow name · run at 10-04 16:23"; clicking the title opens that workflow with its run history on that run. When the session has several pages it shows "Page 2 of 3".
• Resize from any corner or edge. The handles stay hidden until the pointer rests on this browser (the page included). Resizing never moves the card: dragging a corner keeps the opposite corner still, dragging an edge keeps the opposite edge still; width and height stay in the page's proportion, so the card always holds a full 1280 × 800 desktop viewport. With a corner focused, arrow keys resize too (hold ⇧ for bigger steps).
• When several are stacked, the top card's title bar (drag, mute, close) and resize handles are never covered by the pages below; the cards underneath show only their title bars while their pages keep running behind.
• When the app window shrinks, cards are pulled back inside it within the same size limits and proportion, and the new position and size are remembered.
• The speaker button in the title bar controls that page's audio. Unmuting restores both Electron audio and the page player's own mute, volume and host-paused playback state; it stays in sync when the site replaces or creates the player later. The title bar, rounded corners and edges absorb pointer input instead of passing clicks through to workflow nodes underneath.
• Automation keeps rendering while the Mosael window is covered by another window or on another desktop, so infinite scrolling doesn't stall.

Signing in, and staying signed in#

Publishing account cards show a status badge — signed in, login needed, or checking. The recheck button loads the site and looks for evidence you are still authenticated; the result and its timestamp go on the card. When a session dies, the card says so rather than letting the next publish fail.

Rechecking is deliberately evidence-based: it looks for something only a signed-in visitor sees. Treating "the page loaded" as proof is how an account pool ends up insisting you are signed in while every upload fails. The same rule applies while you sign in: nothing on a login page counts as evidence. The 微信快捷登录 (WeChat quick login) card on the WeChat Channels login page is not mistaken for a signed-in session; and when TikTok leaves you on the For You feed with an invisible login dialog still in the page, you are still recognised as signed in and the embedded browser closes itself.

Signing out and signing in again#

• Sign out (publishing accounts) / Clear login data (general profiles) sit in the card's ⋯ menu and its context menu. They clear the cookies, local storage and cache in that profile's partition: a publishing account goes back to login needed; a general profile is signed out of every site in it, and the profile itself stays. Signing out on the website itself is not reliable — some platforms only invalidate the session of the current page while other cookies in the partition survive, so the next open is signed in again. Clearing the partition is the one certain way.
• Sign out and log in again (the key icon, shown while a publishing account is signed in) does the above first, then opens the login page. Opening the login page alone is not enough: a site that sees a valid session in the partition usually bounces you straight back to its home page, and switching accounts never happens.

Each profile can also carry its own proxy, set from the card's context menu. Sessions and exit addresses stay paired, which is what most platforms expect.

Who may use a profile#

This is the part worth reading carefully.

• Publishing uses the account bound to the platform you are publishing to. That is the whole point of binding, and no extra approval is asked for.
• Workflows name a profile explicitly on the node (profile_id, required when the node's session mode is pool), so the flow you built states which identity it uses.
• The agent must ask before it may open a profile at all. Borrowing a login is classed as an external action, so it raises a confirmation card naming the profile — the agent cannot reach an identity you did not hand it.

Two details of that last rule are worth knowing, because they decide how much a single approval buys:

• The card is in the Outside this app tier, so it has no "Always allow this session": every time a profile is opened you press Allow once yourself, and auto-approval never answers for you.
• Approval is on opening the profile. Once a page is open, the agent's interactions inside it — typing, clicking, evaluating — are classed read-only and do not each raise their own card. So an approved browser_pool_open is best read as "you may act as this identity on this site", not "you may take exactly one action".

Treat approval accordingly: it is a decision about which identity the agent may wear, so the question worth asking at the card is whether you want it acting as that account at all.

Profiles you disable with the card's toggle are invisible to publishing and to the agent, without being deleted or signed out.

Sharing in a team deployment#

Accounts and profiles belong to whoever created them and are private by default: other members of the same workspace can't see them and can't use them either. Guessing the id, typing it into a workflow or asking the agent to open it is refused with "This browser profile belongs to someone else and hasn't been shared".

A profile you own can be shared into the workspace from the context menu. Other members can then publish through it and select it in workflows — without the credentials ever passing through anybody's hands, because what is shared is the session, not the password. A publishing account and its browser profile are one identity, shared and withdrawn together; once withdrawn, new publishes and opens by others are refused.

Sharing lends it out for use; it doesn't hand over control. Renaming, disabling or enabling, changing the proxy, rechecking, signing in or again, signing out or clearing data, and deleting are all owner-only — workspace admins included. On a card shared with you only Open remains; calling the API directly is refused too, saying only the owner can do that.

Who counts as the one using it:

• Publish page, Browser pool, import from link: the signed-in person.
• A workflow run by hand: whoever pressed Run. Scheduled and webhook-triggered runs act as the task's owner — the accounts and profiles in the graph must be the owner's own or shared into the workspace; if someone else changed the version being run, they must be able to use them too, or the owner approves that version (see Scheduled tasks).
• The agent: whoever approved the confirmation card.

The workflow pickers for publishing account and pool profile only list the ones you may use.

Browser sessions opened by workflows and the agent#

A workflow's Open browser node has three kinds of session:

• Throwaway: wiped when the run ends; nothing is kept.
• Persistent by name: keeps sign-ins under a name. Within a workspace the same name is the same sign-in, a different name is a different one, and workspaces never share; names can be any text (non-Latin included), up to 80 characters. One sign-in serves one run at a time — if another run holds it you are told so, rather than two runs fighting over the same tab.
• Browser pool: reuses one of the signed-in profiles above, one session per profile at a time.

A session the agent opens belongs to that conversation; if nobody closes it, it is reclaimed after 15 minutes idle instead of holding the name forever. A workflow's session is kept until that run ends — a long generation between two browser steps is normal.

When automation clicks a link that opens a new window, the new page joins the session's page list and the next step already runs on it; use the Browser · switch page node to go back or close it. Downloads automation triggers go straight to the media library: the Browser · navigate and Browser · click nodes gain an asset id output, and the asset's provenance records which run and which node. When the session ends or is cancelled, every page it opened is closed. See Visual workflows → Browser nodes for the nodes.

Where the data lives#

Sessions live under Electron's user data directory (Partitions/), not in the SQLite database. They are per-machine by nature: a browser session is bound to the browser that created it, so switching to a team backend does not carry logins along with it.

Passkeys and platform authenticators#

The browser pool handles account selection for discoverable credentials and checks actual WebAuthn capabilities. Official macOS builds use Developer ID signing, a matching provisioning profile and Apple notarization. On supported Macs with fingerprints enrolled, Touch ID can register and use device-bound passkeys. Unsigned development builds do not enable this capability. Device-bound credentials remain partitioned by browser profile and do not automatically sync from iCloud or a phone. Cross-device QR passkeys are unavailable; choose another login method when the site offers one.