## Summary The desktop app's browser does not retain logged-in sessions even with session persistence configured to the shared setting. Sites that were authenticated previously come back logged out, so every use starts with a fresh login. ## Environment - Claude Code 2.1.235 - macOS 26.6.1 (build 25G76), arm64, Darwin 25.6.0 - Claude Code desktop app (ClaudeCode.app) ## What happens Session persistence is set to shared. Despite that, browser sessions are not remembered - previously authenti

[BUG] Desktop app browser does not retain sessions despite session persistence set to shared

Status Open

Reported on v2.1.235

Maintainer reply None cached

Activity 0 comments · opened Aug 19, 2026

Summary

The desktop app's browser does not retain logged-in sessions even with session persistence configured to the shared setting. Sites that were authenticated previously come back logged out, so every use starts with a fresh login.

Environment

Claude Code 2.1.235
macOS 26.6.1 (build 25G76), arm64, Darwin 25.6.0
Claude Code desktop app (ClaudeCode.app)

What happens

Session persistence is set to shared. Despite that, browser sessions are not remembered - previously authenticated sites present a login screen again rather than restoring the session.

This is filed as a bug rather than a feature request because the setting exists and appears not to take effect. Whatever the intended semantics of the shared option are, the observed behavior is that nothing persists.

Expected

With persistence set to shared, cookies and session state survive across uses, and sites that were logged into stay logged in.

Detail I have not pinned down yet

I would rather file this with honest gaps than guess, so flagging what is still unconfirmed on my side:

Whether the loss happens on app restart specifically, or on every new browser invocation within a single app session.
Whether it affects all sites or only some (for example only those setting particular cookie attributes).
Whether any state at all survives, or nothing does.

Happy to add all of that, plus logs, if you tell me what would be most useful to capture. If there is a known correct way to inspect the browser profile directory on macOS, point me at it and I will attach the relevant state.

Context

This compounds with two sibling reports I am filing on passkey support and on system password manager access in the same embedded browser. Individually each is friction. Together they mean every authenticated site must be logged into manually, by copy and paste, every single time. This one seems the most tractable of the three, since it looks like an existing setting not working rather than a missing platform integration.

View original on GitHub ↗