feat(desktop): browser profiles for the preview browser#7254

🟠 High preview/PreviewMoreMenu.tsx:201

The clear actions target the built-in Default partition when profileId is omitted, even though the menu displays the user's configured default profile. Because PreviewMoreMenu passes the raw optional ID to clearCookies and clearCache, profile-less legacy tabs can clear the wrong profile's data. Resolve the missing ID to DEFAULT_BROWSER_PROFILE_ID before invoking either action.

No longer relevant as of 61d5a1136cade87d21fb98f42d5e93d91b3fdad5

🟡 Medium browser/previewWebviewConfigState.ts:66

A valid profile ID containing \u0000, such as foo\u0000bar, is truncated to foo, so getPreviewConfig loads and returns the partition for the wrong profile. parseConfigKey splits the key on the delimiter even though the ID schemas allow that character; encode the environment/profile pair unambiguously, such as a JSON tuple, instead of splitting on a raw delimiter.

No longer relevant as of 0009cb1daf2c6fea1dbe1643f7ea9fcf298640f1

settings/IntegrationsSettings.tsx:567

This icon-only control deletes the profile and wipes its cookies/cache immediately and irreversibly, while every comparable destructive action in settings confirms first (ThemeSettings.tsx theme removal, ConnectionsSettings.tsx session revocation / Tailscale disable all route through AlertDialog). A stray click here silently destroys stored logins.

Suggest gating removeProfile behind the same AlertDialog confirmation used elsewhere in settings, naming the profile in the title, so the destructive path matches the established pattern.

No longer relevant as of 0009cb1daf2c6fea1dbe1643f7ea9fcf298640f1

🟡 Medium src/browserProfile.ts:67

When userProfiles contains two distinct entries with the same id, resolveBrowserProfiles returns both identities even though they map to the same Electron partition, so cookies and logins leak between profiles the picker presents as isolated and profile lookup becomes ambiguous. The filter removes only built-in collisions; deduplicate user IDs (or reject duplicate IDs during settings validation) before returning the resolved list.

No longer relevant as of 61d5a1136cade87d21fb98f42d5e93d91b3fdad5

🟡 Medium src/browserProfile.ts:33

A custom profile with kind: "incognito" is shown as ephemeral but its cookies are persisted across restarts, because partition creation uses the special incognito ID rather than BrowserProfileKind. Reject kind: "incognito" for non-built-in IDs, or make partition creation derive persistence from kind.

No longer relevant as of 61d5a1136cade87d21fb98f42d5e93d91b3fdad5

Deleted profile cookies can remain

Medium Severity

Removing a profile calls clear cookies/cache for that profile, but clear only touches sessions already in the in-memory map. resolveClearPartitions derives the partition string without creating the session first, so after a restart—or if no tab under that profile was opened this process—the clear is a no-op and persistent cookies stay on disk with no UI entry left.

^{Reviewed by Cursor Bugbot for commit fe1bc48d0b0d5c13e5282191ae42e0973f15d539. Configure here.}

🟡 Medium browser/openFileInPreview.ts:54

Opening a file or link before client-settings hydration permanently creates the tab with the schema-default viewport and profile instead of the user's configured defaults. browserDefaultOpenViewport() and browserDefaultOpenProfileId() read the pre-hydration snapshot synchronously; resolve the hydrated defaults first, as openPreviewSession does, before invoking openPreview.

No longer relevant as of 2d101531aec510d521de30e8772dd011b05b7232

Fixed in 4dca51e1f5e. File/URL and terminal-link opens await settings hydration and use viewport/profile from the same hydrated snapshot; focused tests cover a deferred hydration promise.

ui/menu.tsx:242

:first-of-type doesn't exclude the chevron when the sub-trigger has no leading icon — in that case the chevron is the first (and only) svg child, so it picks up [&>svg:first-of-type]:-mx-0.5. That compound selector has specificity (0,2,1) versus .ms-auto's (0,1,0), so margin-inline: -0.125rem beats the chevron's own ms-auto regardless of class order and the chevron stops being pushed to the right edge. That regresses the two existing icon-less sub-triggers: Appearance in PreviewMoreMenu.tsx:127 and Turn in DiffPanel.tsx:557, whose chevrons would sit flush against the label instead of right-aligned.

Since the chevron is always rendered last, scoping to :not(:last-child) matches only a real leading icon and leaves the chevron's own margins intact.

No longer relevant as of 0009cb1daf2c6fea1dbe1643f7ea9fcf298640f1

Profile delete skips other environments

Medium Severity

Removing a profile clears cookies/cache only for the primary environmentId. Partitions are scoped per environment, so other connected environments keep that profile’s data on disk after the profile disappears from settings.

^{Triggered by learned rule: Multi-environment identity scoping: keys and lookups must carry environmentId}

^{Reviewed by Cursor Bugbot for commit 61d5a1136cade87d21fb98f42d5e93d91b3fdad5. Configure here.}

🟡 Medium settings/IntegrationsSettings.tsx:524

Removing a profile leaves existing tabs attached to its Electron partition, so those tabs can recreate cookies/cache after clearCookies and clearCache, leaving data with no profile UI to manage it. The dialog promises that open tabs move to the default profile, but this code only changes browserDefaultProfileId for future tabs; close or migrate the profile's existing tabs before clearing and removing it.

No longer relevant as of 3045949155d67b9a31a9426eb832c3d0c24ecf64

🟡 Medium settings/IntegrationsSettings.tsx:520

Deleting a browser profile removes its global entry but clears cookies and cache only for the current primary environmentId, leaving data orphaned in every other environment that used the profile. Clear the profile partition for all environments where it may exist, or retain cleanup state until those partitions have been removed.

No longer relevant as of 3045949155d67b9a31a9426eb832c3d0c24ecf64

🟡 Medium settings/IntegrationsSettings.tsx:521

The profile is removed from settings even when clearCookies or clearCache fails, so its cookies or cache can remain on disk with no profile entry available for retry. Both IPC calls are fire-and-forget and their errors are suppressed; await the deletions and only update settings after they succeed, while surfacing failure to the user.

No longer relevant as of 2d101531aec510d521de30e8772dd011b05b7232

Fixed in 210d0f82b3 and c8840bc05b. Removal awaits cookie/cache cleanup across all known environments, retains the profile on failure, and exposes an inline retryable error.

🟡 Medium settings/IntegrationsSettings.tsx:499

Clicking Add profile twice before React rerenders creates only one profile instead of two, because both calls build browserProfiles from the same render-captured userProfiles array and the second updateSettings replaces the first patch. Disable or debounce the action while updating, or use an atomic updater based on the latest settings snapshot.

No longer relevant as of 2d101531aec510d521de30e8772dd011b05b7232

Fixed in 2d101531ae. Add, rename, and post-cleanup removal re-read the current settings snapshot before writing, avoiding stale render snapshots.

Sync opens skip settings hydration

Medium Severity

File and terminal-link preview opens newly apply browserDefaultOpenViewport / browserDefaultOpenProfileId via the sync getters. Unlike openPreviewSession, they never await resolveBrowserDefaults(), so a tab opened before client settings hydrate is born on schema Default and never corrected.

^{Reviewed by Cursor Bugbot for commit 316224d9edd554e1126e946505f7f4fa26472673. Configure here.}

settings/IntegrationsSettings.tsx:551

ITEM_ROW_INNER_CLASSNAME stacks (flex flex-col gap-3) below sm, and it is written for rows that also carry ITEM_ROW_CLASSNAME's py-3 (see ConnectionsSettings.tsx and CloudEnvironmentConnectList.tsx, which always pair the two). Here the rows are bare inside a space-y-1 list, so on a narrow viewport each profile's Remove button drops 12px below its own name input while the next profile's input is only 4px away — the button visually groups with the wrong profile.

These rows are one input plus one icon button, so a plain single-line row avoids the stacking entirely:

This is the only use of ITEM_ROW_INNER_CLASSNAME in the file, so its import can go with it.

No longer relevant as of 3045949155d67b9a31a9426eb832c3d0c24ecf64

settings/IntegrationsSettings.tsx:547

On non-Electron clients this row renders inside DesktopOnlyBrowserDefaults, whose unavailability treatment only dims h3/p ([&_h3]:opacity-64 [&_p]:opacity-64) and relies on each control's own disabled opacity for the rest. The built-in rows here are neither: <span className="… text-foreground"> plus Badge render at full contrast, and with no stored profiles they are the only content in the block, so "Default / Incognito" reads as active while every neighbouring row is dimmed and disabled.

Suggest dimming the list when disabled, e.g. className={cn("mt-1 space-y-1", disabled && "opacity-64")} (needs cn added to the ~/lib/utils import), so the profile rows follow the same unavailable treatment as the rest of the block.

No longer relevant as of 5b85b1db9841333a84c08e3dff77ebaa59fbb923

settings/IntegrationsSettings.tsx:559

The container-level opacity-64 stacks with each control's own disabled treatment, so the user-profile rows end up dimmer than every other row in the block. Input's wrapper carries has-disabled:opacity-64 and Button carries disabled:opacity-64, and both children here also receive disabled, so the rename field and the remove button composite to ~0.41 alpha while the Select, Switch, and NumberField in the neighbouring rows sit at 0.64.

Only the built-in rows lack a self-dimming treatment, so scoping the dim to that span keeps the whole block at one contrast level (the note above can move with it):

No longer relevant as of a7801b6d775068e26dfe115a25bb11c3a7aa27d5

components/RightPanelTabs.tsx:744

Profile names are user-supplied up to BROWSER_PROFILE_NAME_MAX_LENGTH (48), and these rows render the name bare in an unbounded popup. Menu rows carrying user text elsewhere cap and ellipsize instead (ProjectScriptsControl uses <span className="truncate"> inside MenuItem, PullRequestDetailPanel and ComposerStashMenu use min-w-0 flex-1 truncate), so a long name here widens the submenu to fit-content and wraps the row rather than ellipsizing like every other name-bearing menu.

Suggest capping the sub-popup and truncating the label:

No longer relevant as of 7aa90aad3cfd7b8c54854e2f404989a2ce390355

preview/PreviewMoreMenu.tsx:215

The parenthetical repeats the profile name that the MenuGroupLabel directly above already states, and it is the width driver for this popup: with a 48-character name the item label reaches ~65 characters, so the popup grows well past its min-w-56 and the rows wrap (menu rows here have no truncating span, unlike the name-bearing rows in ProjectScriptsControl/ComposerStashMenu).

Suggest letting the group heading carry the profile and keeping the action labels fixed-length:

No longer relevant as of 3045949155d67b9a31a9426eb832c3d0c24ecf64

preview/PreviewMoreMenu.tsx:211

truncate on an inner <span> has no effect here: MenuGroupLabel renders a block div, so the span stays an inline box, and overflow/text-overflow don't apply to inline non-replaced boxes. Only white-space: nowrap takes effect, so a 48-character profile name can't wrap and expands the popup's max-content width well past min-w-56 — the exact widening the comment above says this avoids.

Moving the truncation onto the label itself (a block box) with a max width both caps the popup and yields a real ellipsis, matching the max-w-56 + truncating-item pattern used for the profile submenu in RightPanelTabs:

No longer relevant as of 7aa90aad3cfd7b8c54854e2f404989a2ce390355

settings/IntegrationsSettings.tsx:523

The partition scope is ${environmentId}::${profileId}, but this settings panel has no environment scope of its own and falls back to the primary environment, so removal only clears the profile's partition in that one environment. A tab opened under this profile from a thread in another environment (PreviewMoreMenu passes threadRef.environmentId) keeps its cookies and cache on disk, and when environmentId is still null nothing is cleared at all — while the confirmation dialog states "Its cookies, logins, and cache are deleted with it."

Suggest either clearing across the client's known environments (useEnvironments()) so the promise holds, or softening the dialog copy to match what is actually deleted rather than guessing a single environment.

No longer relevant as of 2d101531aec510d521de30e8772dd011b05b7232

Fixed in c8840bc05b. Profile removal clears the partition in every known environment before removing the global profile record.

components/RightPanelTabs.tsx:945

Routing Browser through MenuSubTrigger drops the shortcut affordance that SurfaceMenuItem gave it: the row no longer renders <MenuShortcut>B</MenuShortcut> and no longer carries aria-keyshortcuts="B", while Terminal/Files/Diff/Pull request/Agents in the same popup still show theirs (and the launcher empty state still shows a Kbd "B"). The shortcut itself still fires via handleAddSurfaceMenuKeyDown, so the hint disappeared while the behaviour stayed — the one row users can't discover is the one that now has a submenu.

Wrapping the label in a flex-1 span keeps the kbd flush right ahead of the chevron (whose own ms-auto would otherwise split the free space with the kbd's):

No longer relevant as of 2d101531aec510d521de30e8772dd011b05b7232

Fixed in f5bb21e27d6 and ee989a8c07. Browser displays its B shortcut and aria-keyshortcuts; the shortcut and chevron share a stable right-aligned group.

🟠 High methods/preview.ts:235

Distinct environment/profile pairs can resolve to the same Electron partition, causing tabs to share cookies and storage across supposedly isolated contexts. Because EnvironmentId and BrowserProfileId permit :, the ::-joined scope is ambiguous; encode each identifier before joining them.

✅ Resolved in 2d101531aec510d521de30e8772dd011b05b7232

Fixed in 4271e1541ac and 082c63134a. Scope components are encoded independently, and nondefault profiles use a disjoint partition namespace. Tests cover delimiter-pair collisions, default environment a::b versus environment a/profile b, and unchanged legacy Default partition names.

preview/PreviewView.tsx:708

The full profile name is surfaced with a native title, which the repo has moved away from (t3code/no-native-title-tooltip, "Use Tooltip + TooltipTrigger + TooltipPopup from components/ui/tooltip"). It only escapes the rule because Badge is a capitalized component — Badge renders a <span> and forwards the prop straight through, so the DOM ends up with exactly the banned native tooltip. Every other hover label in this same chrome row (PreviewChromeRow's nav buttons) and every other truncated label elsewhere (ServerUpdateAction, ProviderModelPicker, DiffPanel) uses the styled Tooltip, which is themed and shows on keyboard focus; the native one is neither.

Suggest wrapping the badge in Tooltip (also needs import { Tooltip, TooltipPopup, TooltipTrigger } from "~/components/ui/tooltip";):

No longer relevant as of 2d101531aec510d521de30e8772dd011b05b7232

Fixed in ee363dafcd3. The profile badge uses the shared Tooltip components and preserves truncation.

Deleted tabs do not switch profiles

Medium Severity

Removing a profile only wipes that partition and drops it from settings. Open tabs keep the deleted profileId and stay attached to the now-empty partition. The confirmation dialog still says those tabs move to the default profile, which does not happen.

^{Reviewed by Cursor Bugbot for commit 05ae35c3b79430e2247eaba8101036fb860a29aa. Configure here.}

While removal is in flight the onOpenChange guard above swallows every close request, so this Cancel button stays enabled, focusable, and hoverable but does nothing (same for Esc). The other in-flight confirmations in settings disable the close explicitly — ConnectionsSettings does this for the Tailscale disable, WSL backend, and server-exposure dialogs — so the pending state reads the same everywhere.

^{Posted via Macroscope — UI Consistency}

Putting MenuShortcut inside a MenuSubTrigger gives this row two auto inline-start margins: the kbd (ms-auto) and the primitive's chevron (-me-0.5 ms-auto). Flexbox distributes the leftover space equally between auto margins, so "B" lands roughly halfway between the label and the chevron and its position shifts with the popup width — while Terminal/Files/Diff/Pull request/Agents in the same popup render their shortcut flush against the right padding edge (single ms-auto in MenuItem).

Neutralizing the chevron's auto margin lets the shortcut absorb the free space, so the shortcut/chevron pair sits flush right and the shortcut column stays stable:

^{Posted via Macroscope — UI Consistency}

Empty catalog blocks profile removal

Low Severity

The remove control only waits for environmentsReady, but clearBrowserProfileData rejects an empty environment list. A ready catalog with no entries still enables Remove, then every confirmation fails and the profile stays.

^{Reviewed by Cursor Bugbot for commit 2d101531aec510d521de30e8772dd011b05b7232. Configure here.}

Fixed in fccf30726a8. Removal availability includes a desktop bridge and a ready, non-empty environment catalog. Both the row action and an already-open confirmation reflect unavailable cleanup, with an explanation; the handler retains its guard instead of deleting metadata without clearing data. Focused availability tests pass.

🟠 High methods/preview.ts:241

resolvePartitionScope throws URIError for a profile or environment ID containing a lone surrogate, so getPreviewConfig and profile-scoped data clearing fail even though the IPC schema accepts the ID. Normalize the strings to well-formed Unicode before calling encodeURIComponent so these requests still derive a partition.

The tooltip's !removalAvailable branch ("Connect to an environment to remove this profile") is unreachable: buttonVariants carries disabled:pointer-events-none, and a natively disabled button also can't be hovered or focused — so exactly when the explanation is needed, the trigger emits no events. Settings already handles this by making a wrapper the trigger (ConnectionsSettings.tsx's CloudLinkSwitch renders <TooltipTrigger render={<span className="inline-flex">{control}</span>} /> for its disabled-reason tooltip).

Suggest wrapping the button the same way so the reason stays reachable:

^{Posted via Macroscope — UI Consistency}

Fixed in 11dc366428c. An enabled, focusable wrapper now owns the unavailable-reason tooltip around the disabled removal button, so mouse and keyboard users can reach the explanation.

🟡 Medium settings/IntegrationsSettings.tsx:531

Clicking Add profile before client settings hydration completes writes DEFAULT_CLIENT_SETTINGS plus the new profile, overwriting persisted profiles and other client-local preferences. addProfile reads getClientSettings() during the hydration race; disable the action until hydration finishes or apply the update only after using the hydrated snapshot.

Fixed at #7254 fe5480b817 and preserved through the table rewrite in #7255 d95c81c935. Profile creation, rename, removal, default selection/reset, and import setup now use the existing client-settings hydration gate, including handler guards. The upper import path reads latest hydrated settings for registration after await. Lower web typecheck and 50 focused tests pass.

These rows render user-supplied profile names (up to BROWSER_PROFILE_NAME_MAX_LENGTH, 48) bare in an uncapped popup, so the popup takes its width from the longest name — the same profile list in RightPanelTabs' submenu now caps and ellipsizes (min-w-40 max-w-56 + <span className="min-w-0 truncate">), and KeybindingsSettings does the same for its long option values (w-fit min-w-44 + truncating span). The trigger already truncates via SelectValue, so today the selected name ellipsizes in the row while the same name blows the popup out.

Suggest capping the list and truncating the item text so both profile pickers behave the same:

^{Posted via Macroscope — UI Consistency}

Profile names do not truncate

Medium Severity

The default-profile picker caps the list at max-w-64 and wraps names in a truncate span, but SelectItem renders children inside ItemText, so that span is an inline descendant rather than a flex item. text-overflow never applies, and whitespace-nowrap from truncate stops wrapping. Long profile names (up to 48 characters) overflow or clip without an ellipsis after the width cap.

^{Reviewed by Cursor Bugbot for commit cd654b4cf8597af890c8311852acda84bacde5e5. Configure here.}

Width cap misses the popup shell

Low Severity

max-w-64 is passed as SelectPopup className, which styles the list, not the glass wrapper. matchTriggerWidth still sets min-w-(--anchor-width) on that wrapper. When the trigger is w-full (settings rows stack below sm), the shell stays as wide as the trigger while the list is capped at 16rem, leaving empty popup chrome.

^{Reviewed by Cursor Bugbot for commit cd654b4cf8597af890c8311852acda84bacde5e5. Configure here.}

Fixed in 1cb5acff41. The cap now goes on the glass shell via popupClassName as well as the list, and matchTriggerWidth={false} stops the shell tracking a full-width trigger — same shape as the keybinding pickers.

matchTriggerWidth={false} drops the only min-width the popup shell has: dropdown-glass sets none, and with alignItemWithTrigger={false} the in-data-[side=none]:min-w-[calc(var(--anchor-width)+1.25rem)] on SelectItem never applies either. So this popup is purely content-sized — with just "Default" in the list it renders ~80px wide under a sm:w-44 trigger, while every other settings select (BrowserViewportSetting, zoom, appearance, frame rate, SettingsPanels, ConnectionsSettings) keeps the default matchTriggerWidth, so its popup is never narrower than the control it opens from.

The empty-chrome case the comment above describes comes from the list not filling the shell, not from matching the trigger: with w-full on the list, the shell stays ≥ trigger width (and ≤ max-w-64 wherever the trigger is narrower than 16rem) and the items truncate against whatever width the shell ends up with.

The explanatory comment just above would need its trigger-width sentence updated to match.

^{Posted via Macroscope — UI Consistency}

Fixed in 06e1411676. Restored the trigger-width match and put w-full on the list, so the shell is never narrower than the trigger (and never wider than 16rem); comment updated.

🟠 High preview/BrowserSession.ts:153

getPartition assigns the same partition to distinct scopes such as "p\ud800" and "p�", so those profiles share cookies and site storage. TextEncoder().encode(scope) replaces lone surrogates with U+FFFD before hashing; use an encoding that preserves UTF-16 code units when deriving the digest.

Fixed in 4414469f35. Lone UTF-16 surrogates are escaped to \\uXXXX before the digest (with a literal backslash doubled so the escape can't be forged), so "p\\ud800" and "p\\ufffd" hash to different partitions. Every well-formed scope passes through byte-for-byte unchanged, so existing partitions and the logins in them stay put — the test pins both the separation and the historical scope-a hash.

🟡 Medium components/RightPanelTabs.tsx:937

When the panel has no surfaces, users cannot open Incognito or a custom browser profile directly; RightPanelEmptyState only invokes onAddBrowser, which always creates the default-profile tab. The profile submenu is mounted only when props.surfaces.length > 0, so users must first create an unwanted default tab to reach it. Make the profile choices available from the empty-panel launcher as well.