Sidebar browser guests lose site logins on restart: give the workspace partition a persist: identity

[tanyicheng1750]

Sidebar browser guests lose site logins on restart: give the workspace partition a persist: identity

Summary

The built-in Sidebar browser keeps its cookies in an in-memory Electron session, so every site login (ChatGPT, GitHub, any account-scoped page) is lost each time the desktop app restarts. One-line fix: give the per-workspace partition a persist: identity, exactly like platform-view.ts already does for the account window.

Why it happens

apps/desktop/src/browser-guests.ts:24-41:

/**
 * Reserve one guest in a workspace's process-lifetime partition.
 * ...
 */
async acquire(owner, workspace) {
  let partition = this.partitions.get(workspace)
  if (partition === undefined) {
    partition = `dsh-sidebar-browser-${randomUUID()}`   // ← no `persist:` prefix
    this.configureSession(session.fromPartition(partition))
    this.partitions.set(workspace, partition)
  }
  ...
}

Two independent consequences of the missing prefix:

1. Electron treats a partition name without persist: as a memory-only session: cookies, localStorage, IndexedDB and cache never reach disk. On quit they are gone.
2. The name contains randomUUID(), so even if the storage were persisted, the next launch would compute a different name and open a different (empty) profile.

The doc comment is explicit about the intent — "process-lifetime partition" — but the visible effect is that the Sidebar browser is a fresh browser on every launch, while the rest of the app (profile, chats, plugin state) is persistent. Users notice this as "the sidebar browser logged me out again".

Why it cannot be worked around from a plugin

Worth stating because it is the reason this needs an upstream change rather than a workaround:

• partition is chosen in the main process and handed back through the lease; the IPC request carries only the workspace key, so a plugin cannot ask for a different partition.
• will-attach-webview in bind() (line ~76) rejects any webview whose params.partition !== lease.partition, so a plugin cannot create its own persist: guest in the sidebar either.
• The guest page's own JS cannot re-authenticate itself either: session tokens for most sites are HttpOnly (__Secure-next-auth.session-token on chatgpt.com), invisible to executeJavaScript, so nothing readable can be exported and replayed into a fresh partition.

Net effect: any plugin that drives the built-in browser (there are several in the dsh-plugin topic) starts every session logged out, and the only remedies available to it are "ask the user to log in again" or "patch app.asar" — the latter breaks the code signature, so it is not a real option.

Proposed change

apps/desktop/src/browser-guests.ts:

-import { randomUUID } from 'node:crypto'
+import { createHash, randomUUID } from 'node:crypto'
@@
-      partition = `dsh-sidebar-browser-${randomUUID()}`
+      partition = `persist:dsh-sidebar-browser-${createHash('sha256').update(workspace).digest('hex')}`

That is the whole patch. It follows the precedent already in this directory — platform-view.ts:105:

: `persist:dsh-platform-${createHash('sha256').update(JSON.stringify([account.origin, account.userId])).digest('hex')}`

Properties

• Isolation is unchanged. One workspace still maps to exactly one partition; the hash is the workspace key, so two workspaces never share a cookie jar. Nothing about leases, release(), attached, or configureSession() needs to change.
• will-attach-webview keeps working as-is — it compares params.partition against the lease, and the lease now carries the persistent name.
• Storage location is the usual one: <userData>/Partitions/dsh-sidebar-browser-<sha256(workspace)>/Cookies, encrypted with the same Safe Storage key the app already uses, so no new at-rest exposure beyond what the account window (persist:dsh-platform-…) already has.
• Bounded growth: one directory per workspace that has used the Sidebar browser, no per-launch directories (the current code leaks nothing on disk precisely because it never writes).
• Cache on disk also means the Sidebar browser stops re-downloading assets on each launch.

Things a reviewer may want to decide

1. Cleanup semantics. A workspace deleted from the profile leaves its Partitions/ directory behind. release()'s "workspace storage survives" comment becomes literally true on disk, so a GC step (or accepting the residue) should be a conscious choice.
2. Logout semantics. "Clear data" in the Sidebar UI must keep deleting the partition, otherwise a user cannot get rid of a stale login. Worth checking that path explicitly.
3. Test. apps/desktop/tests/ already has a spec for platform partitioning; a parallel assertion that two different workspaces get different persistent names, and the same workspace gets the same name across two DesktopBrowserGuests instances, would pin the behaviour.

Environment

• macOS 26.5, arm64
• @deepseek-ai/dsh-desktop 0.2.1-rc.3, Electron 44.7.0, Chrome 152
• Observed with a plugin driving the built-in Sidebar browser: after every restart the tab is at https://chatgpt.com/ showing "Log in"

[0xlic]

+1 — I have the same requirement and am experiencing the same issue.

I built [dsh-chatgpt-panel](https://github.com/0xlic/dsh-chatgpt-panel), a plugin that embeds ChatGPT in the DSH desktop UI using dshDesktop.browser.acquire() and the returned partition.

Signing in works during an app session, but after fully quitting and reopening DSH, the embedded page loses its login state and requires signing in again.

Environment: macOS, DSH Desktop 0.2.1-rc.5.

An opt-in persistent partition with a stable identity across app restarts would meet my needs, without requiring cookie access or weakening the existing guest isolation. An explicit “clear site data” action would also make sense.

Happy to test a pre-release build with this capability. Thanks!