Repository navigation
[Feature]: Per-project default browser profile (so agent-opened tabs use the right profile) #13254
Description
Activity
Also posted in Discussions → Ideas, since that's where the issue templates point feature requests: #13255. Happy for either one to be closed in favour of the other.
Triage
Confirmed against current
main. A new browser tab that does not name a profile uses one client setting,browserDefaultProfileId. Nothing on the project overrides it, andpreview_opencannot pass a profile. The report matches the code. It is a feature request, not a bug.What the code does
browserDefaultProfileIdlives on client settings inpackages/contracts/src/settings.ts.browserDefaultOpenProfileIdinapps/web/src/browser/browserDefaults.tsresolves that single value. A missing profile falls back todefault. Incognito is excluded, so it cannot be the stored default.Both hand-opened tabs and agent opens go through that helper:
openPreviewSessionsendsinput.profileId ?? browserDefaultOpenProfileId(defaults).- When
preview_openhas no tab to reuse,PreviewAutomationHostssendsbrowserDefaultOpenProfileId(defaults)and nothing from the thread's project. PreviewAutomationOpenInputhas noprofileId. The otherpreview_*tools do not take one either.
reuseExistingTabdefaults to true, so an agent keeps the session's current tab and its profile. The partition is fixed when the Electron guest attaches (profileIdonPreviewSessionSnapshot). There is no action to move an open tab onto another profile. The hand path is a new tab: the right-panel add menu and the empty-panel Browser chevron calladdBrowserSurfacewith aprofileId. Those choices show up only once more than one profile exists.Project settings do not store a profile.
ProjectSettingsOverridescovers model, workspace, scripts, andenableAgentBrowserAccess, which is only the on/off gate for agent browser tools. The project settings Browser row is that gate. Profiles stay in client settings because the Chromium partition is desktop-local. A profile id stored on the server would not exist on another desktop, or on mobile.Cookies are partitioned by environment plus profile (
resolvePartitionScopeinapps/desktop/src/ipc/methods/preview.ts), not by project. Every project on that desktop shares one profile's logins. A global default is what mixes the work and personal accounts.The toolbar already names the profile, and only when the tab's profile differs from the resolved global default (
PreviewView,leadingActions). A tab on the global default shows no badge.Related work, not this request
- #9704 (open) adds an optional
profileIdonpreview_openand returns it from status. That is the explicit agent argument from the writeup. Calls that omit it still use the global default, and the PR does not add a project setting. It does not cover the unattended case. - #9402 (closed, not merged) asked agent-created tabs to honor the configured default. That behavior is already on
main. Agents do followbrowserDefaultProfileId. The gap is that the value is global. - #8256 (open) would put
projectIdinto the partition so one profile's cookies no longer cross projects. That isolates jars. It does not choose which existing profile a project opens. - Discussion #13255 was the same writeup and is closed as a duplicate of this issue.
Next step
Keep this issue as the tracker for a per-project default profile. A useful shape:
- A client-local per-project profile, defaulting to the global profile, resolved in
browserDefaultOpenProfileIdso agent-created tabs and hand-opened tabs share it. - Leave an explicit profile from the add-tab menu as an override for that one tab.
- Treat #9704's
profileIdargument as separate. An agent that passes it is asking, not inheriting the project.
Until then, set the global default under Settings → Integrations → Browser before the agent opens a new tab, or open the tab from the profile submenu. An existing tab stays on the profile it was created with.
- locked and limited conversation to collaborators
on Oct 11, 2026
Before submitting
Area
apps/web (Settings → Browser) and the agent browser/preview tools
Problem or use case
Browser profiles are a great addition. I use them to keep two worlds apart: one profile is logged into my work accounts and one is logged into my personal/client accounts. Mixing them up means signing into the wrong account or giving an agent access to the wrong world.
The problem is that the profile a new tab uses is decided by a single global setting (
browserDefaultProfileId, set with "Set as default" in Settings → Browser). When an agent opens a browser, it always gets that one profile, whatever project the thread belongs to.In practice:
preview_open,preview_navigate, …) don't accept a profile.Proposed solution
Let a project (workspace root) set its own default browser profile:
browserDefaultProfileId→default.profileIdonpreview_open, so agents or skills can ask for a specific profile explicitly. If the requested profile doesn't match the project's profile, it's reasonable to show a warning or refuse.A simpler first step that would already solve most of this: store an optional
browserProfileIdon the project and use it instead ofbrowserDefaultProfileIdwhen a thread in that project opens a tab.Why this matters
Profiles exist to keep cookies and logins separate. Today the separation only holds if the user remembers to flip a global setting, and agents open tabs without asking, so the risky moments are exactly when nobody is watching. A per-project default makes the safe behaviour automatic. It matters most for people who do client or freelance work next to a day job, or who run several clients in parallel.
Environment
T3 Code (Nightly) 0.0.43-nightly.20260922.2123, macOS.