[Bug]: Agents ignore the default browser profile, cannot accept human-opened tabs, and cannot select another profile #16701

Activity

1. juliusmarminge commented on Oct 7, 2026

   

   juliusmarminge

   on Oct 7, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Verified on main (365aa8798) against the three claims. Claim 1 is a clear actionable bug on Desktop; claims 2–3 match intentional ownership / product gaps (not regressions in existing API behavior).

   1. Global default profile ignored by agent-created tabs — confirmed bug

   Human opens go through openPreviewSession, which always stamps profileId: input.profileId ?? browserDefaultOpenProfileId(defaults) from Settings → Integrations → Browser (openPreviewSession.ts, browserDefaults.ts).

   Agent preview_open does not use that path. It calls manager.open with only threadId, optional url, runtime: "server", reveal: false, and automationOwner — no profileId (ServerBrowser.ts). The snapshot therefore omits profileId (matches your t3_preview_list note).

   On Desktop, the webview is born from that snapshot: profileId={snapshot.profileId} (ElectronBrowserHost.tsx). undefined / "default" both resolve to the built-in Default partition, not browserDefaultProfileId (resolvePartitionScope). So a custom global default is honored for human-opened tabs and ignored for agent-opened ones.

   Headless footnote: if no desktop attaches, agent tabs also force an isolated ephemeral Playwright context whenever automationOwner is set (profileId ?? "default" is only the cache key; storage is still blank) (ServerBrowser.ts, ServerBrowserContexts.ts, L105-L109). Your Desktop repro is the partition-default mismatch above.

   Likely fix direction: when creating an agent tab (or when the desktop mounts a server tab with missing profileId), apply the same resolved default as browserDefaultOpenProfileId so agent-created Desktop tabs land in the configured profile partition. Server cannot read client settings today, so this is either a client-side fallback on attach or plumbing the default into the open path.

   2. Human → agent handoff refused — intentional ownership, not a code bug

   requireTab / SessionControl.agent require tab.control.agentId === request.agentSessionId (ServerBrowser.ts, SessionControl.ts). Human-opened tabs have no automationOwner, so agentId is null → the exact "belongs to another agent session or a human" / PreviewAutomationControlInterruptedError you hit (previewAutomation.ts).

   The tool text documents this: "Server tabs use isolated storage and cannot be operated by a different agent session." (preview/tools.ts). Restoring handoff (or a transfer API) is a product decision, overlapping #16532.

   3. No profileId on preview_open — confirmed API gap (feature)

   PreviewAutomationOpenInput only has url / open / show / reuseExistingTab (+ tab target fields) — no profile field (previewAutomation.ts). Human PreviewOpenInput already has optional profileId with “omit → client default” (preview.ts). Explicit agent selection was attempted in closed unmerged #9704 (closed for missing verification, not as wontfix). Per-project defaults remain open in #13254 / #13262 — related but not the same as “honor global default on agent open.”

   Related (not duplicates)

   • #15328 — server browser / ownership model this sits on.
   • #9704 — closed unmerged profile selection for agents.
   • #13254 / #13262 — per-project defaults.
   • #16532 — broader “use signed-in tabs” CUA ask.
   • No open/merged PR found that wires browserDefaultProfileId into the agent preview_open path.

   Next step

   Treat claim 1 as the bug to fix (agent/Desktop opens should honor the configured global default profile the way human openPreviewSession already does). Keep claims 2–3 as separate product work (handoff / explicit profileId on preview_open), not blockers for landing the default-profile fix.

   Thanks for the precise nightly build, t3_preview_list field differences, and the three-way breakdown — that made the split straightforward.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 7, 2026
3. baptisteArno commented on Oct 8, 2026

   

   baptisteArno

   on Oct 8, 2026

   Contributor

   More actions

   Same here on 0.0.46-nightly.20261008.2813 (macOS, desktop app + local server).

   This completely breaks my personal agent workflow. I log into my accounts in the T3 browser, then the agent browses those logged-in sessions for me. Since the server browser landed, it can't anymore:

   • I log into developers.facebook.com in a tab I opened (runtime: "server", profileId: "default", control unclaimed).
   • The agent calls preview_navigate / preview_open with that tabId and gets "This browser tab belongs to another agent session or a human. Open your own tab."
   • The agent opens its own tab instead: no profileId, HeadlessChrome UA, no cookies, so it lands on the Meta login page.

   Looks like a regression from #15328. Before it, agent tabs opened with browserDefaultOpenProfileId(defaults) (PreviewAutomationHosts.tsx), so they shared the user's partition. Now:

   • SessionControl.agentId is readonly and set once from automationOwner (SessionControl.ts#L16), so a human tab (agentId === null) can never be driven by an agent, even when unclaimed (ServerBrowser.ts#L1443).
   • The agent open path never passes a profileId (ServerBrowser.ts#L1510-L1516) and any tab with an automationOwner gets a fresh isolated context (ServerBrowser.ts#L709-L713).

   Isolation by default makes sense, but I need an opt-in. Either of these would fix it for me:

   1. A "Lend to agent" action on a human tab, which assigns agentId when it's null. The agent gets the exact tab and cookies.
   2. A setting so agent tabs open in the default profile (or a chosen one), like before feat(preview): run the browser on the environment server #15328.

   Happy to help test a fix.
4. juliusmarminge

   closed this as completedin #16956on Oct 9, 2026