On October 22, 2026, The Browser Company announced that Arc — the browser that made vertical tabs, Spaces and a command-bar workflow fashionable — will stop working on Mac and Windows on December 22, 2026. It is currently the #1 story on daily.dev Popular, and it landed hard because Arc was not a neglected side project: it was the product that put the company on the map. But if you build browser automation for a living, the interesting part of this story is not the obituary. It is the pattern. A browser you depend on can go into maintenance mode, then get a sunset date, then stop working — and every script, session and extension workflow built on top of it has to move, on someone else's schedule.
We run browser automation that touches production systems: scraping pipelines, lead enrichment, unattended workflows that log in, fill forms and move data between systems. Our Shopee security-headers research taught us how much of the web's behaviour lives in the browser layer — TLS fingerprints, tokens, bot detection — and our dark software factories piece covered what breaks when nobody is watching. Arc's shutdown is the same lesson from a different angle: the browser is a dependency, and dependencies need a migration plan before they announce one. This piece is that plan, written from the automation side.
1. What actually happened, and why the dates matter
The shutdown is staged, and the staging is the part automation builders should study:
- October 22, 2026: the announcement. No new Arc accounts can be created. Existing users keep browsing, and a final update adds a data-export option.
- November 23, 2026: Arc Search on iOS and Android loses its AI features and sign-in/tab sync. The mobile apps keep working as basic local browsers.
- December 22, 2026: Arc on Mac and Windows stops working entirely. Accounts are deactivated, and account data is deleted within 30 days.
The company says users should move to Dia, its AI-first browser, which imports Arc's Spaces, pinned tabs, passwords and extensions. It also says it cannot open-source Arc, because Arc runs on a proprietary internal SDK — the Arc Development Kit — that also powers Dia. Keeping a browser secure, the company wrote, "takes constant, dedicated work that is only increasing in the age of AI," and it will not do that work twice.
Two details matter more than the headlines. First, feature development on Arc had already stopped in 2025, when the company pivoted to Dia. The sunset date is not the moment Arc died; it is the moment the death became official. If you waited for the announcement to start migrating, you were already a year late. Second, the kill is staged, not instant — sync dies before the browser does, and mobile dies differently from desktop. Any automation that depended on Arc sync, on a signed-in profile, or on a mobile flow had a shorter runway than the December date suggested. Sunset timelines always have a hidden early deadline. Plan for it.
2. Target the engine, not the product
Arc was a Chromium browser with a different shell: a sidebar instead of a tab strip, Spaces instead of windows, a command bar instead of an address bar. Underneath, pages rendered with Blink, JavaScript ran on V8, and the network stack was Chromium's. That distinction is the whole game for automation.
If your scripts drive the product — clicking Arc's sidebar, relying on a Space layout, scripting the command bar — they die with the product. If they drive the engine — Playwright or Puppeteer against Chromium, the Chrome DevTools Protocol (CDP), standard DOM and network APIs — they survive, because the engine lives on in Chrome, Edge, Brave and every other Chromium build.
The practical rule we follow, from our how we work philosophy of automating aggressively but keeping the blast radius small:
Never automate a browser brand. Automate a rendering engine plus a version.
In Playwright, that means launching by channel or executable path, never by "whatever browser the operator has installed":
// Pin the engine, not the brand.
const browser = await chromium.launch({
channel: 'chrome', // or executablePath to a vendored build
headless: true,
args: ['--no-sandbox', '--disable-dev-shm-usage'],
});
const context = await browser.newContext({
userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36',
});
And in CI, vendor the browser build instead of downloading "latest" on every run:
# Pin it in the lockfile era: the browser version is a dependency.
npx playwright install chromium --with-deps
npx playwright --version # record this in the run log, every run
A branded browser is a UI. An engine version is a contract. When the brand dies, the contract transfers to the next Chromium build with, in our experience, only minor breakage — usually a changed CDP method or a new default header, not a rewrite.
3. Sessions are the real migration, not the browser
Ask any Arc user what they will miss and they will not say "the rendering engine." They will say their Spaces, their pinned tabs, their logged-in sessions. For automation, the equivalent is the authenticated profile: cookies, localStorage, session tokens, extension state. Losing the browser is annoying; losing the sessions is expensive, because re-authenticating against dozens of sites means CAPTCHAs, 2FA prompts and rate limits — the exact things automation exists to avoid.
Treat session state as portable data, from day one, not as something that lives inside one browser's profile folder:
// Export: after a successful login, persist the whole context state.
await context.storageState({ path: 'sessions/client-a.json' });
// Import: on any Chromium build, restore it and verify before doing work.
const context = await browser.newContext({
storageState: 'sessions/client-a.json',
});
const page = await context.newPage();
await page.goto('https://example-app.com/dashboard');
await page.waitForSelector('[data-testid="user-menu"]', { timeout: 15000 });
Three rules make this work in practice:
- Export on success, not on schedule. The storage-state file should be rewritten every time a login flow completes cleanly, so the newest file is never more than one successful run old.
- Verify after import, before work. A restored session that silently expired will produce a login page instead of a dashboard, and a script that does not check will happily scrape the login page and record garbage. The selector check above is the cheapest guard you can write.
- Keep sessions out of the browser's own sync. Arc's sync dying on November 23 — a month before the browser itself — is the cautionary tale. If your sessions only exist inside a vendor's sync cloud, the vendor's timeline becomes your timeline. Files on disk, encrypted at rest, backed up like any other credential store, are yours.
One more migration detail Arc users discovered the hard way: extensions do not always transfer cleanly. Extension storage, extension settings and extension-granted permissions are per-browser state. If a workflow depends on an extension (a scraper helper, a session manager, a form filler), test it on the target browser before migration day, not after. Extensions are the most common "it worked in Arc, why is it broken in Chrome?" surprise, because nothing in the export step warns you.
4. The fingerprint changes when the browser changes
Our Shopee research showed how aggressively the web fingerprints browsers: TLS fingerprints (JA3/JA4), header order, navigator properties, canvas and font signals. Switching browsers changes your fingerprint, and fingerprint changes trip bot detection, fraud checks and "unusual sign-in" flows.
A migration checklist for the fingerprint-sensitive parts of a pipeline:
| Signal | What changes on browser switch | Mitigation |
|---|---|---|
| TLS fingerprint (JA3/JA4) | Chromium version and build change the ClientHello | Keep the Chromium major version close to the old one; test against the target's bot checks before cutover |
User-Agent and navigator
|
Brand tokens and version strings change | Set an explicit, consistent UA per context; never let it default to whatever the new install reports |
| Header order | Minor differences between builds | Drive through one automation library so headers are generated identically |
| Cookies / tokens | Session state may not transfer | Export storage state (section 3) and re-verify logins |
| IP / network | Nothing, if the machine is unchanged | Keep the egress IP stable during migration week so "new browser + new IP" does not stack |
The key insight: migrate one variable at a time. New browser on the same machine, same IP, same Chromium major version, same UA string — then change the other variables later, once the new baseline is proven. A migration that changes the browser, the machine and the network on the same day is un-debuggable when something breaks, and something always breaks.
5. Maintenance mode is the real sunset announcement
Arc's timeline teaches a monitoring lesson. The official sunset came in October 2026, but the actionable signal came in 2025, when new-feature work stopped. For automation builders, the equivalent signals are:
- The vendor stops shipping features for the browser, the automation library, or the extension you depend on.
- Release cadence slows or security patches arrive late.
- Docs stop being updated — new APIs documented for the successor, not the product you use.
- The community migrates — Stack Overflow answers, GitHub issues and blog posts start assuming the successor.
Build a lightweight watch for the browsers and libraries in your stack: a monthly check of release notes and a quarterly "is this still maintained?" review. The cost is an hour a quarter. The cost of missing the signal is a forced migration under a vendor's deadline, which is how you end up re-authenticating forty accounts in a week.
The same logic applies one level down, to the automation libraries themselves. Playwright, Puppeteer and Selenium all track Chromium's release train; a CDP method deprecated in one Chromium release disappears a few releases later. Pin versions, read the changelog before upgrading, and run your suite against a canary build in a separate job so a breaking change shows up as a canary failure, not a production outage.
6. A shutdown-proof automation checklist
Here is the checklist we now apply to every browser-based workflow, and the one we would hand to anyone migrating off Arc this month:
- Engine abstraction. All flows go through Playwright/Puppeteer APIs against a pinned Chromium version. No product-specific UI scripting, no reliance on a branded browser's chrome.
- Vendored browser builds. The browser binary is installed from a pinned version in CI, and its version is logged on every run.
- Portable sessions. Storage state exported on every successful login, encrypted at rest, restorable on any Chromium build, verified before use.
- Extension inventory. Every extension a workflow needs is listed with its store ID and version, and tested on the target browser before cutover.
- Fingerprint baseline. UA, headers and TLS behaviour recorded for the old setup; the new setup is diffed against it before it takes production traffic.
- Matrix testing. The suite runs against at least two Chromium builds (stable + previous) so a single build's regression never blocks the pipeline.
- Human gate on migration. Moving sessions and credentials between browsers is a privileged operation. A human approves it, the way our dark-factories piece argues for checkpoints anywhere a machine's mistake is expensive. Automation moves the data; a person authorizes the move.
- EOL watch. A quarterly review of every browser, library and extension in the stack, asking one question: is this still maintained, and what is the exit plan if it is not?
None of this is exotic. It is the boring infrastructure that makes the difference between "Arc died and we migrated in a week" and "Arc died and our pipelines are down." The teams that survive a browser shutdown are not the ones with the cleverest scripts; they are the ones whose scripts never depended on the browser that died.
7. What to do this week if you are an Arc user
If you personally run Arc, the vendor's own path is straightforward: export your data with the final update, import into Dia (or Chrome, or any Chromium browser), and check that passwords, bookmarks and extensions arrived intact before December 22. Do the export early — sync-dependent data has the November 23 deadline, not the December one.
If you run automation on Arc — and some teams genuinely did, because Arc's profile model suited multi-client work — do not migrate the browser first. Migrate the sessions and the scripts first: export storage state, re-point the launcher at a pinned Chromium build, run the suite against the new target, and only then decommission the Arc profile. The browser is the last thing you change, not the first.
Arc deserved its cult following. It genuinely rethought the browser's interface, and its ideas — vertical tabs, Spaces, a command bar — have already spread to other browsers. But interfaces are not infrastructure. Browsers, like every other dependency, have lifecycles. Build for the lifecycle, and the next shutdown announcement will be a migration ticket, not an emergency.
FAQ
Is Arc really shutting down, or just stopping development?
It is shutting down. The Browser Company announced on October 22, 2026 that Arc on Mac and Windows stops working on December 22, 2026, with accounts deactivated and data deleted within 30 days. Development had already stopped in 2025; this is the end of the product, not a pause.
Does Dia replace Arc for automation?
Dia is the vendor's recommended successor and imports Arc data, but it is a consumer browser with an AI layer, not an automation target. Automate against a pinned Chromium build through Playwright or Puppeteer, not against Dia's UI.
Will my extensions and logins survive a move to Chrome?
Extensions install from the Chrome Web Store on any Chromium browser, but their stored settings may not transfer — test them. Logins transfer only if you export session state or re-authenticate; a browser's own sync is not a migration plan.
What is the single most important migration step?
Export and verify your session state before the sync deadline. Everything else — scripts, fingerprints, extensions — can be fixed after cutover. Lost sessions mean re-authentication, and re-authentication at scale is where migrations actually fail.
References
- The Browser Company, Arc sunset announcement (October 22, 2026), via TechCrunch: https://techcrunch.com/2026/10/22/arc-browser-sunsets-december-22-as-the-browser-company-doubles-down-on-dia/
- The Register, "Arc browser on its way out as makers suggest an alternative" (October 23, 2026): https://www.theregister.com/software/2026/10/23/arc-browser-on-its-way-out-as-makers-suggest-an-alternative/5305114
- Playwright documentation, Browser launch options and storage state: https://playwright.dev/docs/api/class-browser and https://playwright.dev/docs/auth
- Chrome DevTools Protocol documentation: https://chromedevtools.github.io/devtools-protocol/
- Botslave, "Shopee Security Headers: TLS, Tokens & Bot Detection": https://botslave.com/blog/shopee-security-headers-tls-tokens-bot-detection
- Botslave, "Dark Software Factories: What Runs Lights-Out and What Breaks Without a Human in the Loop": https://botslave.com/blog/dark-software-factories-lights-out
- Botslave, "How we work": https://botslave.com/how-we-work
Originally published on botslave.com. Botslave is an automation studio — see what we build and how we work.
Top comments (0)