Browser profiles: share a custom profile's cookies across all environments

[jkracz]

Problem

Browser profiles look global, but their cookies are per environment.

With more than one environment connected, I create a profile and sign in to sites under it (or import cookies from Chrome). Then I open a preview tab under that same profile from a thread in another environment, and I'm signed out of everything. The profile name, the list in Settings → Integrations → Browser profiles, and the settings scope showing "All environments" all suggest one shared identity, but each environment gets its own empty cookie jar behind the same name.

Importing makes it worse. The import wizard always writes into the primary environment's partition, so there's no way in the UI to get imported cookies into the other environments. The workaround is to sign in again in every environment, for every profile.

Evidence from main (3e6b450)

• The profile list is client-local settings, so every environment sees the same profiles (browserProfile.ts).
• The Electron partition is derived from [environmentId, profileId], or just environmentId for Default (resolvePartitionScope).
• Import targets primaryEnvironment.environmentId only (IntegrationsSettings.tsx).

History

• The original preview browser (52c77c1) used one shared partition, with the design note: "The shared persist:t3code-preview partition keeps cookies in sync."
• 6c6740e ("Refine collaborative browser preview") changed it to getBrowserPartition(environmentId). I couldn't find a stated reason for scoping cookies by environment.
• feat(desktop): browser profiles for the preview browser #7254 (browser profiles) kept Default on that legacy partition so upgrading wouldn't sign anyone out, and scoped custom profiles by environment + profile.

Proposal

Make custom profiles one identity across environments: derive their partition from the profile id alone.

• Default stays per environment, so nobody is signed out, which keeps feat(desktop): browser profiles for the preview browser #7254's compatibility guarantee.
• Incognito stays in memory as it is now.
• Import into a custom profile then works for every environment, and clear/remove only has one partition to touch.

Cookies live on the desktop machine either way. Partitions are local to the Electron app and are never sent to a remote environment, so sharing a profile across environments doesn't move any data off the device.

Questions for maintainers

1. Was the environment scoping in 6c6740e intentional? If so, what should it protect against?
2. Existing custom-profile cookies are split across environments. Should the shared partition start empty (users sign in again once), or adopt the primary environment's partition? I lean toward starting empty for simplicity.

If this direction and scope look right, I'm happy to send a PR.

[IGOLz]

Up

[BusuL]

+1, with a fleet use case.

I run T3 across several machines: a macOS desktop plus a Linux box (t3 serve) where most agents run, and sometimes more servers. Today each environment keeps its own cookie jar, so every sign-in (Google, Cloudflare-protected dashboards, our own admin panel) has to be repeated per machine, and server-side profiles live under a temporary --user-data-dir unless a desktop client has reported them (see #19805 / #19279).

What would make this work for multi-machine setups:

• One profile identity across the fleet. Signing in once under a profile makes that session available to every environment that uses the profile — synced via the T3 server/account, or exported/imported explicitly per environment.
• Explicit, auditable sync. Choose which profiles sync, see where they're present, and revoke a profile from one environment without signing out everywhere.
• Persistent by default on servers. Server-hosted profiles should survive restarts without a client reconnecting.

Codex's in-app browser keeps its own persistent state, and its Chrome extension lets agents use the real signed-in Chrome profile when needed; something equivalent at fleet scope would remove most of the manual sign-in work for agents.

[svetch]

+1, with a concrete proposal and one more gap this thread doesn't cover yet: the server browser.

Setup

Linux desktop app plus a remote environment on a Hetzner box over T3 Connect. I browse in desktop tabs, and agents on the remote environment drive the remote server browser (headless Chromium under ~/.t3/userdata/server-browser/profiles/<profileId>). For one profile ("Quantum") that means three cookie jars today:

Jar	Where	Filled by
desktop partition [primaryEnvId, profileId]	desktop	cookie import (always lands here)
desktop partition [remoteEnvId, profileId]	desktop	only manual sign-in
server browser profiles/<profileId>	remote host	only manual sign-in, or "Open in 's browser"

The original proposal here (partition from the profile id alone) fixes the first two rows. Agents on a remote environment never use a desktop partition, though. A desktop app can't drive a remote server's tabs, so they always run in that host's server browser. That third jar is the one that matters for agent work, and nothing in the UI can seed it.

Proposal: model it on "Pull request sharing"

Settings → Source control already has Pull request sharing: a per-machine list where each machine is set to off, read, or read-and-act, and the setting applies only to this device. Browser profiles could use the same pattern:

• Profile sharing, per profile × per environment: Off / Seed on import / Keep in sync.
• Seed on import: the import wizard (and feat(web): add browser cookie import option to preview toolbar menu #29156's toolbar entry) gets a target-environment picker that includes each trusted environment's server browser. The desktop sends the decrypted cookies over the existing authenticated environment connection, and the server applies them with Playwright context.addCookies() on that profile's persistent context. This avoids writing the SQLite file while Chromium holds it.
• Keep in sync: debounced, newest last_update_utc wins per (host, name, path, partition key), plus a per-environment revoke that clears only that environment's copy, as BusuL suggested above.
• Default stays per environment and Incognito never syncs, as already proposed.

Because sharing signed-in sessions with agents on another machine is a real trust decision, it should be explicit per environment, like PR sharing.

Workaround, and evidence it's feasible

I'm running a small script for now. It decrypts Helium's cookies (Linux keyring key, v11), re-encrypts them for the server browser, and merges them by newest last_update_utc into server-browser/profiles/<profileId>/Default/Cookies after stopping that profile's headless Chromium. The server browser runs with --password-store=basic, so its cookies are v10 with the fixed Linux key and the cookie DB v24 domain-hash prefix. About 3,500 cookies across three profiles merged cleanly. The only rough edges were having to stop the running Chromium (#25981 would mostly remove that) and the partition/profile mapping living outside T3.

Happy to test a PR on a desktop + remote Linux setup.