Claude Desktop slow startup — eager loading of all conversations + stale worktree validation
Resolved 💬 3 comments Opened Mar 24, 2026 by Vgccorner Closed Mar 28, 2026
Summary
Claude Desktop takes 30-60+ seconds to restart because it eagerly loads all conversations, validates all git-worktrees, and synchronously reconnects all bridges on startup.
Environment
- macOS Darwin 25.1.0
- Claude Desktop (latest)
- 18GB in
~/Library/Application Support/Claude/ launchPreviewPersistSession: true- Active bridge connections (Cowork)
- 3 scheduled tasks (local agent mode)
What happens
- On app launch, ALL conversations load simultaneously (not paginated)
git-worktrees.jsoncontains stale entries pointing to deleted paths. App appears to validate each entry on startup.- Bridge connections attempt synchronous reconnection, blocking the UI
- If bridge has queued messages (e.g., after PC restart), all messages flush at once, potentially causing ECONNRESET
- Total startup time: 30-60s before the app is interactive
Expected behavior
- Startup in <5 seconds with lazy loading of non-active conversations
- Stale worktree entries auto-pruned (path doesn't exist → remove entry)
- Bridge reconnection async (don't block UI)
- Message queue capped to prevent flood on reconnect
Workarounds found
- Manually clearing
git-worktrees.json(echo '[]' > ~/Library/Application\ Support/Claude/git-worktrees.json) reduces startup time - Clearing
bridge-state.jsonprocessedMessageUuids prevents message flood on restart - Setting
launchPreviewPersistSession: falseskips state restoration (but loses session context)
Suggested improvements
- Lazy conversation loading — paginate, load only recent/pinned conversations on startup. Load older ones on scroll (virtual list).
- Stale worktree pruning — auto-remove entries where the path no longer exists on disk instead of validating dead paths every startup.
- Async bridge reconnection — don't block UI thread. Show "reconnecting..." state and let the user interact with local sessions immediately.
- Bridge message queue cap — limit
processedMessageUuidsto 20-30 entries. Older UUIDs are unnecessary dedup tracking. - Session priority queue — reconnect sessions with
scheduledTasksor active bridges first. Idle conversations can lazy-load.
Impact
For users with persistent agent sessions (Cowork, scheduled tasks, bridge connections), slow restarts create a painful loop: bridge gets stuck → need to restart → restart takes 60s → bridge may get stuck again on message flood. This makes the Cowork/bridge feature significantly less reliable for power users.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗