Sign up
View stargazersSign up

[Bug]: Dev desktops in every worktree share one Chromium profile#15426

openedOct 4, 2026byAAlex

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. In worktree A, run vp run dev:desktop and create a custom theme in Settings → Appearance.
  2. Stop it. In worktree B, which has a fresh, empty .t3, run vp run dev:desktop.
  3. Open Settings → Appearance.

Expected behavior

Worktree B starts clean. Its dev server already uses the worktree's own .t3, so renderer storage should be separate too.

Actual behavior

Worktree B shows the theme created in worktree A. B's .t3/userdata/client-settings.json has no themes, so the data comes from Electron's renderer storage.

Every dev desktop uses the same Chromium profile, whichever worktree or T3 home it runs from:

  • DesktopUserData.resolveUserDataPath returns the fixed <appData>/t3code-dev in development (or T3 Code (Dev) if that legacy folder exists). The worktree and T3 home are not part of the path.
  • The dev renderer always loads from t3code-dev://app (ElectronProtocol.ts), so the per-worktree Vite port doesn't separate storage by origin either.
  • Only the macOS bundle ID is per-worktree (com.t3tools.t3code.dev.<slug> in electron-launcher.mjs).

Reading the profile on macOS, ~/Library/Application Support/t3code-dev/Local Storage under t3code-dev://app contains t3code:themes:v1 (with the leaked theme), t3code:composer-drafts:v1, t3code:terminal-state:v1 and t3code:ui-state:v1.

What's shared across worktrees today:

  • Custom themes and theme selection
  • Composer drafts, terminal state and UI state that point at another worktree's threads and projects
  • Preview browser cookies and logins: persist:t3code-preview-<sha256(scope)> partitions, and the default scope is "shared"
  • Clerk desktop session cookies

Running two dev desktops from different worktrees at once probably hits the same IndexedDB backing-store lock that #12480 fixed for packaged V1/V2 (there are no single-instance locks). #12480 explicitly left development profile handling unchanged.

Impact

Minor bug or occasional failure

Version or commit

main @ a21702d0e5

Environment

macOS 26 (Darwin 25.6), vp run dev:desktop from linked git worktrees

Workaround

None in the app. Clearing t3code-dev resets every worktree at once.

Possible fix

In development, put the Electron profile under the T3 state dir, e.g. path.join(stateDir, "electron") in resolveUserDataPath (both callers already pass the full environment). Each worktree's gitignored .t3 then owns its renderer storage, --home-dir gives a truly clean profile, and deleting a worktree removes its profile. One cost: the main checkout's dev profile moves from <appData>/t3code-dev to ~/.t3/dev/electron once, so dev-only drafts, themes and Clerk sign-in there start fresh.

Adding the bundle-ID slug to the folder name would also work, but profiles would pile up under Application Support after worktrees are deleted.

JJulius MarmingeOct 4, 2026

Note

Grok responding on behalf of Julius.

Triage

Thanks for the detailed write-up, @PixPMusic. I could confirm it: a dev desktop doesn't follow the worktree's .t3 (or T3CODE_HOME), so every development process shares one Electron profile and renderer storage leaks across worktrees.

DesktopUserData.resolveUserDataPath returns <appData>/t3code-dev in development, or <appData>/T3 Code (Dev) when that legacy folder exists, without looking at the worktree or the T3 home. Both callers, startup (DesktopAppIdentity) and the Clerk bridge (DesktopClerk), already pass the full environment including stateDir. The dev origin is always t3code-dev://app, so the per-worktree Vite port doesn't separate storage either. Themes, drafts, terminal and UI state live in localStorage rather than client-settings.json, which is why that file looked empty.

Two details look a little different from the report:

  • Running two dev desktops at once. Beyond the IndexedDB lock risk, the Clerk bridge takes Electron's profile-scoped single-instance lock, and DesktopClerk.configure quits when it isn't the primary instance. On the shared dev profile, the second process would likely exit during startup.
  • Preview logins. Preview partitions live inside the profile, but preview IPC scopes them by environment id, so a fresh worktree doesn't automatically reuse another worktree's preview logins. The cookies are still stored in the shared profile, though.

Likely fix area

resolveUserDataPath in the desktop app, development branch only. Some options:

  • Put the dev profile under the state dir, as you suggested (path.join(stateDir, "electron"), which is ~/.t3/dev/electron with no T3CODE_HOME). That would follow --home-dir and be removed with the worktree. The trade-off is a one-time fresh dev profile (including Clerk sign-in), and the legacy T3 Code (Dev) fallback would need handling so existing machines don't keep sharing it.
  • A bundle-id-based folder name, which wouldn't follow --home-dir and would leave folders behind after worktrees are deleted.

Packaged profiles (#12480) and the t3code-dev://app scheme, which Clerk allowlists depend on, would likely stay as they are either way.

A maintainer will decide on the fix direction.

JJulius Marminge21d ago

Fresh triage at main commit 07d38b8d17167c8d17fba1184dbe13a307fada74: this is an ordinary bug report, not a reported exploitable vulnerability. Source inspection confirms DesktopUserData.resolveUserDataPath still selects a fixed development profile, and DesktopClerk.make sets that directory as Electron userData. Changing it also changes the session-cookie profile, so the automated triage authentication/credentials hard stop requires maintainer handling. No implementation or runtime reproduction was performed; desktop remains unverified. Leaving the issue open.