The agent that shops for you shouldn’t be using your mouse
Every cross-border operator I know is quietly running the same experiment right now: pointing a coding or browser agent at the boring parts of the stack — pulling Seller Central reports, refreshing supplier quotes, screenshotting a competitor’s PDP, QA-ing a checkout flow on a staging store. The blocker is almost never the model. It’s that the agent needs a desktop, and the moment you give it yours, it takes over your screen mid-task. Windows jump to the front, the cursor moves on its own, a simulator boots over your spreadsheet. That’s the problem offstage is trying to solve, and it’s more relevant to e-commerce ops than the developer-tool framing suggests.
What offstage actually does — and why the mechanism matters
Built by Viraat Das under the Exla FLOPs banner, offstage gives your agent its own macOS user account instead of your session. The maker’s own framing of the pain is worth quoting: every time his coding agent tested a Mac app it had just built, “it took over my screen: windows jumping to the front, the mouse moving on its own, a Simulator booting in the middle of whatever I was doing.”
The fix is a second user, logged in behind yours via fast user switching, with its own window server, framebuffer, and keyboard/mouse stream. A small Swift daemon inside that account launches apps, takes screenshots, and posts clicks through CGEvent’s per-session tap — so input physically cannot land on your screen. Critically, it refuses to send input at all if its session ever becomes the one on the console.
That’s the detail that separates this from the “run it in the background” tools. Most background automation assumes the background stays the background. offstage treats “my session became foreground” as a hard stop rather than a race condition to lose gracefully.
Routing is tiered, and this is where it gets interesting for anyone running multi-surface ops:
- Headless commands run in place.
- Headed browsers go to a Linux container with a virtual display.
- macOS GUI work goes to the second account.
- Installers are refused outright.
It isn’t a VM. The helper account takes about 3 GB and there’s nothing to boot. It’s free, MIT licensed, and Apple Silicon only. Setup is a paste-into-your-agent prompt that registers it as an MCP server via npx -y --package=@viraatdas/offstage@latest offstage-mcp, installs the CLI, and creates the session. Codex and opencode work too, with configs in the README.
Why Amazon sellers should care more than Shopify ones
If your storefront is Shopify, almost everything an agent needs is already an API call. Orders, inventory, fulfillments, even theme edits — the Admin API covers it, and you never need a rendered browser. The marginal value of a second desktop is low.
Now look at Amazon Seller Central. Half the workflows that matter — case logs, reimbursement claims, the Brand Registry dispute flow, A+ content previews, inventory reconciliation screens, the parts of Advertising Console that still don’t expose clean reporting endpoints — are browser-only or browser-adjacent. Same story for TikTok Shop Seller Center, Temu’s seller portal, and SHEIN’s supplier side. These are GUI surfaces wearing an API costume, if they wear one at all.
That asymmetry is the whole argument. A Shopify-first operator can ignore offstage. An Amazon-plus-TikTok-plus-Temu operator running three portals in parallel is exactly the person who needs the agent to have its own screen.
The session-sharing question is the real product decision
The most substantive exchange on the launch thread came from Wandrille Stutz, who asked the obvious operational question: what happens when the agent needs to act on a site where only your local browser is logged in? The second account and the Linux container start clean — no cookies, no Apple Keychain.
The maker’s answer is a deliberate design choice, not a gap: “neither side gets your logins.” The helper account has its own login keychain and browser profiles. Setup skips the Apple ID step, so it isn’t signed into iCloud, and it can’t open your ~/Library, where your browser profiles and keychain files live. Copying a Chrome profile across wouldn’t help anyway — Chrome encrypts cookies with a key stored in your own keychain.
His stated reason: “An agent that can reuse your browser can act as you on every site you’re signed into.”
I think that’s the right call, and I’d push it further than he does. For a cross-border seller, “an agent that can act as you on every site you’re signed into” isn’t a hypothetical risk — it’s your Seller Central account, your ad spend, your payout settings, and your tax documents. Amazon’s own account health and unauthorized-access policies are unforgiving about shared credentials and unusual session behavior. A separate identity for the agent is not paranoia; it’s the minimum viable hygiene.
The practical workflow he describes: you log in on the agent’s side once, during setup, doing 2FA yourself. The account persists, so those cookies survive until the site expires them. He recommends a separate test account where possible. For Playwright work, run npx playwright codegen --save-storage=auth.json, log in by hand, and load the file with storageState — the container mounts your repo read-only, and you keep the auth file out of git because it holds a live session.
Where the math breaks
Three things I’d flag before anyone wires this into production ops.
Cookie decay is your new uptime metric. Because sessions aren’t shared, every portal that expires its cookies becomes a manual re-auth chore. Amazon session lifetimes are short and unpredictable. TikTok Shop is worse. Multiply that by the number of marketplaces you sell on and the “set it and forget it” promise gets thinner every week. Budget for a human to babysit logins, or accept that your agent goes dark periodically.
The 3 GB figure is a floor, not a ceiling. That’s the helper account at rest. Add a headed browser, a few tabs, and a screenshot loop, and you’re consuming real RAM on a machine that’s also running your actual work. On a 16 GB MacBook Air, this is fine. On a loaded machine, it’s a tax you’ll feel.
Apple Silicon only, Mac only. Not disclosed whether Linux or Windows support is planned. If your ops team is on Windows — and plenty of cross-border teams are — this is a non-starter today.
What cross-border sellers can borrow from it
Even if you never install offstage, three patterns here are worth stealing for your own agent stack.
Separate identities, not shared sessions. Whatever automation you’re running — Zapier, Make, a custom n8n flow, a browser agent — give it its own credentials and its own account wherever the platform allows sub-users. Amazon’s User Permissions exist for exactly this. Stop logging agents in as the owner.
Tiered execution by blast radius. offstage’s routing — headless in place, headed in a container, GUI in a sandbox, installers refused — is a clean mental model. Map it to your own ops: read-only report pulls can run anywhere; anything that touches pricing, ad bids, or inventory quantities should run in the most isolated tier you can afford.
Refuse rather than race. The “refuse input if its session is on the console” behavior is the design principle I’d most like to see copied elsewhere. Most automation tools retry until they win. Retrying is how you get a phantom click landing on the wrong window at the wrong moment. Hard refusals with a clear failure signal are worth more than optimistic retries.
Auth files are secrets, not artifacts. The auth.json guidance generalizes: any saved session state your agent uses should be treated like a password, kept out of version control, and rotated on a schedule.
Where my judgment says it falls short
The launch thread is thin on the questions I’d actually ask. There’s no discussion of logging, audit trails, or what happens when an agent session does something wrong on a marketplace portal — which, given Amazon’s account health framework, is the scenario that keeps sellers up at night. If an agent session trips a bot-detection heuristic on Seller Central, whose problem is that? Not disclosed.
There’s also no mention of cost beyond “free and MIT licensed.” Free at the license level doesn’t mean free at the operational level — someone still has to provision the account, manage re-auth, and debug when the daemon doesn’t fire. For a solo operator, that’s an evening. For a team, it’s a runbook nobody wants to own.
And I’d gently push back on the framing. The maker built this for coding agents testing Mac apps. The e-commerce use case is adjacent, not native. There’s no Seller Central integration, no marketplace-aware tooling, no opinion about which portals are safe to automate and which will get you suspended. That’s fine — it’s infrastructure, not a vertical product — but sellers should understand they’re adopting a general-purpose primitive and building the vertical logic themselves.
The Gal Dayan question in the thread is the one I’d most want answered before deploying: when the refusal fires, does the task fail cleanly with a reportable error, or does it sit and retry until you switch away from the console? The maker didn’t respond on-thread. My read of the description — “it refuses to send input at all if its session is ever the one on the console” — suggests a hard fail, which is the right behavior, but I’d want to verify it empirically rather than take it on faith.
What I’d watch / test next
This week, before you touch offstage, do the audit: list every marketplace portal your team logs into manually because there’s no usable API. Rank them by how much time they eat. That list is your automation backlog, and it’s also your answer to whether a second desktop is worth the setup.
Then run the smallest possible test. Spin up the helper account, log into one non-critical portal — a supplier dashboard, not Seller Central — and point an agent at a read-only task: pull a report, screenshot a page, export a CSV. Watch what happens to your own session while it runs. If your screen stays yours, you’ve validated the core promise.
After that, stress the failure modes. Force the refusal by switching to the agent’s session mid-task and see whether it reports cleanly or hangs. Let a cookie expire and time how long re-auth takes. Measure actual RAM under load, not at rest.
And keep a separate test account for every marketplace where you can get one. The moment you’re tempted to share your owner login with an agent is the moment you’ve found the line you shouldn’t cross — regardless of how good the sandbox is.
