[BUG] Claude Code - Persistent Logout & Configuration Loss Bug Report
Claude Code - Persistent Logout & Configuration Loss Bug Report
Environment
- Platform (select one):
- [x] Anthropic API
- [ ] AWS Bedrock
- [ ] Google Vertex AI
- [ ] Other:
- Claude CLI version: 1.0.11 (Claude Code)
- Operating System: macOS 15.5.0 (Darwin Kernel Version 24.5.0)
- Terminal: Warp Terminal
Bug Description
Claude Code persistently logs users out and loses all configuration settings including:
- Authentication session
- Theme preferences
- MCP server configurations
- All personalized settings
This occurs after system events like battery drain, laptop sleep, or unexpected shutdowns, making the development experience frustrating and unreliable.
Steps to Reproduce
- Set up Claude Code with authentication
- Configure theme preferences
- Set up MCP servers
- Work on development projects normally
- Experience a system event (battery drain, forced shutdown, extended sleep)
- Restart laptop and attempt to use Claude Code
- Observe that user is logged out and all configurations are lost
Expected Behavior
- Authentication session should persist across system restarts
- Theme preferences should be saved and restored
- MCP server configurations should be preserved
- User should not need to reconfigure everything after normal system events
- Settings should be stored in a persistent location that survives system events
Actual Behavior
- User gets logged out completely
- All theme preferences reset to default
- MCP servers configuration completely disappears (shows "No MCP servers configured")
- User must manually reconfigure everything from scratch
- This creates significant workflow disruption and productivity loss
Frequency
- Occurs consistently after system events
- Has happened multiple times (at least twice in recent days)
- Appears to be a recurring pattern, not a one-time issue
Impact
- High - Causes significant workflow disruption
- Forces complete reconfiguration of development environment
- Leads to lost productivity and frustration
- Makes Claude Code unreliable for regular development work
Additional Context
System Context
- Development machine: MacBook Pro with Apple Silicon (arm64)
- Common scenario: Working on development projects with Claude Code active
- Triggering events: Battery depletion, forced restarts, extended system sleep, MCP server configuration with Claude piping
Previous Incident Pattern
Critical Discovery: A previous logout/reset occurred without battery loss during MCP server configuration. The incident happened while configuring an MCP server that uses "Claude piping" functionality, where Claude Code can serve as an MCP server itself (claude mcp serve).
Suspicious Configuration Evidence: The searchable directories found in ~/.claude/config.json match directories that were being configured during the previous incident:
{
"searchableDirectories": [
"/Users/codaveto/Repos/Forks/flutter-packages",
"/Users/codaveto/Repos/Forks/flutter-packages/turbo_response"
]
}
This suggests the MCP configuration process may be writing to or modifying Claude Code's internal configuration in ways that trigger instability or reset behavior.
Configuration Lost
- Authentication tokens/sessions
- Theme settings (dark/light mode preferences)
- MCP server configurations (complete loss of server setups)
- Any personalized UI preferences
Expected Configuration Persistence
The following should persist across sessions:
- User authentication (secure token storage)
- User preferences (theme, UI settings)
- MCP server configurations
- Project-specific settings
Suggested Investigation Areas
- Authentication Token Storage: Check if tokens are stored in temporary locations that get cleared on restart
- Configuration File Location: Verify if config files are being saved to persistent directories
- MCP Server Config: Investigate why MCP configurations completely disappear
- Session Management: Review session persistence mechanisms
- macOS Keychain Integration: Consider using macOS Keychain for secure credential storage
- MCP Piping Configuration Safety: Investigate how
claude mcp serveand MCP server configuration affects Claude Code's internal state - Directory Scope Conflicts: Examine how MCP server scoping (local/project/user) interacts with Claude Code's searchable directories configuration
Logs/Debugging Information
- Current MCP status: "No MCP servers configured"
- No error messages displayed during logout
- Silent failure - user only discovers the issue when trying to use Claude Code again
Actual Configuration Analysis
Current Configuration Files Found
Configuration is stored in ~/.claude/ directory with the following files:
MCP Server Configuration (~/.claude/.mcp.json):
- Contains 12 configured MCP servers including TAV2, context7, Firecrawl, Supabase, Google Drive, and others
- All servers have proper configuration with API keys and environment variables
- File shows extensive setup that gets completely lost during logout events
Settings (~/.claude/settings.json):
{
"model": "opus"
}
Search Directories (~/.claude/config.json):
{
"searchableDirectories": [
"/Users/codaveto/Repos/Forks/flutter-packages",
"/Users/codaveto/Repos/Forks/flutter-packages/turbo_response"
]
}
MCP Server Logs Show Connection Issues
From ~/Library/Logs/Claude/mcp.log, the logs reveal a pattern of server connections followed by unexpected disconnections:
Recent Session (2025-05-18T22:12:02):
- All 7 MCP servers initialize successfully
- Servers establish connections and receive initialization messages
- Within 2-3 seconds, all servers disconnect unexpectedly with transport closure errors
- Error pattern: "Server transport closed unexpectedly, this is likely due to the process exiting early"
Specific Error Messages:
[error] [supabase] Server disconnected. For troubleshooting guidance, please visit debugging documentation
[error] [markdownify] Server disconnected. For troubleshooting guidance, please visit debugging documentation
[error] [gdrive] Server disconnected. For troubleshooting guidance, please visit debugging documentation
[error] [mcp-server-firecrawl] Server disconnected. For troubleshooting guidance, please visit debugging documentation
Root Cause Analysis
- Configuration Persistence: Config files exist and are properly formatted, but Claude Code appears to ignore them after logout events
- MCP Server Instability: Servers connect but immediately disconnect, suggesting process management issues
- Authentication State: No authentication tokens found in accessible config files, suggesting they may be stored in macOS Keychain or temporary locations that get cleared
- MCP Configuration Corruption: Previous incident occurred when configuring MCP servers with Claude piping functionality, suggesting MCP configuration process may trigger system instability
Critical Technical Findings
- Configuration files are preserved but not being loaded after logout
- MCP servers show successful initialization followed by immediate disconnection
- The disconnect pattern suggests Claude Code process management issues rather than configuration corruption
- All servers fail simultaneously, indicating a systemic issue rather than individual server problems
Diagnostic Information for Claude Code Team
Confirmed Configuration Locations
- Primary config directory:
~/.claude/ - MCP configuration:
~/.claude/.mcp.json(confirmed working config with 12 servers) - User settings:
~/.claude/settings.json - Search directories:
~/.claude/config.json - Log files:
~/Library/Logs/Claude/mcp.log
Authentication Token Storage
Authentication tokens are NOT found in the readable configuration files, indicating they are likely stored in:
- macOS Keychain (recommended but may be getting cleared)
- Memory-only storage (problematic for persistence)
- Temporary directories that get cleared on restart
MCP Configuration Corruption Pattern
Key Finding: The searchable directories configuration appears to be left over from MCP server setup, specifically when configuring servers that access local repositories. This suggests:
- MCP Scope Confusion: MCP servers can be configured with different scopes (local/project/user), and the configuration process may be incorrectly writing to Claude Code's global configuration
- Claude Piping Side Effects: Using
claude mcp serve(Claude Code as MCP server) may create feedback loops or configuration conflicts - Directory Persistence: The fact that these directories persist in
config.jsonafter MCP configuration suggests the MCP setup process is modifying Claude Code's core configuration files
Reproduction Path: The bug may be reproducible by:
- Configuring MCP servers with local directory access
- Setting up Claude Code as an MCP server (
claude mcp serve) - Creating MCP servers that reference local repositories/directories
- The configuration process appears to modify Claude Code's internal settings, potentially triggering logout/reset behavior
Current Session Information
- Working directory:
/Users/codaveto/Repos/Forks/prompt-forge-ui-builder - Shell:
$SHELLenvironment - Terminal: Warp Terminal
- Architecture: arm64 (Apple Silicon)
Workaround
Currently, the only workaround is to manually reconfigure everything:
- Re-authenticate with Claude Code
- Reset theme preferences
- Reconfigure all MCP servers
- Restore any custom settings
This is time-consuming and disruptive to development workflow.
Priority: High - This severely impacts user experience and productivity Category: Authentication & Configuration Management Affected Versions: 1.0.11 (likely affects other versions)
It just happened again, I had 5 instances running in 3 different projects. I closed one instance with Ctrl + C and then started it again. It showed me the Welcome to Claude Code message, I then closed the tab in hopes that it would not be reset again. However as you can see in the screenshot it was. I have to auth myself again and add all MCP servers as well. Luckily I have them somewhere and Claude Code can add them globally based on that, but it's getting pretty annoying. No idea why it happened this time.
edit: Might worth noting everything kept working fine in the other sessions, but from experience I know that would only last until I ended the session. I have now logged back in and restored the MCP servers.
Courtesy of Claude Code:
Debug Information for Claude Code Issue #1676
MCP Server Configuration Loss After Restart
Issue Summary
Claude Code restarted itself, logged the user out, and lost all MCP server configurations. This is the third occurrence of this issue.
Environment Details
- Claude Code Version: 1.0.17
- macOS Version: 15.5 (24F74) - Darwin 24.5.0
- Node Installation: Using Homebrew (
/opt/homebrew/bin/node) - Shell: zsh with custom Claude alias
- Date: June 8, 2025
Key Findings
1. Multiple Claude Processes
There are 5 Claude CLI processes running in different terminal sessions, plus the Claude desktop app processes:
codaveto 68760 claude (terminal session s005)
codaveto 59507 claude (terminal session s016)
codaveto 56270 claude (terminal session s010)
codaveto 48768 claude (terminal session s002)
codaveto 40885 claude (terminal session s001)
This might indicate:
- Multiple concurrent sessions could be causing conflicts
- Possible race conditions when accessing configuration files
2. Configuration File State
~/.claude/.mcp.json: Last modified May 27, 20:11 (old timestamp)~/.claude/settings.json: Empty{}~/.claude/settings.local.json: Contains MCP permissions but no server configurations{ "permissions": { "allow": [ "Bash(claude mcp add -s user dart -e DART_TOKEN=XXX npx -y dart-mcp-server)", "Bash(claude mcp add:*)" ] }, "enableAllProjectMcpServers": false }- No project-specific directory found for
bwai
3. Missing Logs
No log files found in standard locations:
- No Claude logs in
~/Library/Logs - No
.logfiles in~/.claude/ - No apparent crash reports or error logs
4. Shell Configuration
User has a custom alias in .zshrc:
# Claude fix for env -S issue
alias claude='/opt/homebrew/bin/node /opt/homebrew/bin/claude'
Potential Issues Identified
- Configuration Storage Inconsistency: The MCP configuration appears to be stored separately from the
.mcp.jsonfile (which has an old timestamp) - Runtime Storage: The actual user-scoped MCP configurations might be stored in the
__store.dbfile or elsewhere - Process Synchronization: Multiple Claude processes could be causing state synchronization issues
- No Persistent Logging: Lack of logs makes it difficult to trace what happens during the failure
Recommendations for Developers
1. Add Comprehensive Logging
Implement detailed logging for:
- MCP server configuration changes (add/remove/update)
- Authentication state changes
- Configuration file reads/writes
- Process lifecycle events
- Error conditions and stack traces
2. Investigate Storage Mechanism
- The
.mcp.jsonfile timestamp suggests configs might be stored elsewhere - Check if
__store.dbis where runtime configurations are actually stored - Ensure proper file locking when multiple processes access configuration
- Document the actual storage location and format for MCP configurations
3. Handle Multiple Processes
- Implement proper IPC or file locking to prevent configuration conflicts
- Consider using a single configuration service process
- Add mutex/semaphore protection for configuration file access
- Implement configuration change notifications across processes
4. Add Recovery Mechanism
- Backup configurations before updates
- Implement configuration validation on startup
- Add ability to restore from backup if primary config is corrupted
- Consider versioning configuration files
5. User Experience Improvements
- Add clear error messages when configuration is lost
- Provide automatic backup/restore functionality
- Show warnings when multiple Claude instances are detected
- Add a
claude mcp backupandclaude mcp restorecommand
Additional Context
This appears to be a critical issue affecting user workflow, especially given it's happened three times to the same user. The lack of error logs and the fact that configurations are completely lost (not just corrupted) suggests this might be related to:
- Authentication token expiration causing a full reset
- Process cleanup routines being too aggressive
- Storage location being cleared during some update or cleanup process
Restored MCP Servers
The following servers were restored from the user's backup:
- TAV2 (Tavily search)
- dart (Dart package server)
- context7 (Upstash context)
- mcp-server-firecrawl (Web scraping)
- figma-developer-mcp (Figma API)
- gdrive (Google Drive)
- supabase (PostgreSQL database)
- supabase-postgrest (REST API)
- markdownify (Markdown conversion)
- puppeteer (Browser automation)
- local-context (Local repository scanner)
- imagen-3-0-generate-google (Google's Imagen 3.0)
Aaaand again.. 😩
I'm experiencing the same thing on PopOS 22.04 (Ubuntu based), have been experiencing this since 1.0, roughly. In my case, every time I restart my computer claude loses its configuration, mcp, everything. I'm forced to setup everything again. Sometimes a restart is not even needed to trigger this bug. Using GNOME Terminal.
Same problem. After new login on max plan all configuration is lost and gone; empty config file.
I encountered this issue twice last week. All my configuration and MCP server setup was lost. Fortunately, I have a setup script for MCP servers, but this issue is quite frustrating. I haven’t noticed any patterns that could trigger this. I didn’t restart my MacBook either.
I just had this happen twice, back to back, losing my (global) MCP configuration twice! argh
And just now a third time: seems like the latest update (1.0.29) seems to happen each time I start up
This happened to me just now when I tried using a configuration of this form:
{
"mcpServers": {
"language-server": {
"command": "/full/path/to/your/clone/mcp-language-server/mcp-language-server",
"args": [
"--workspace",
"/path/to/workspace",
"--lsp",
"language-server-executable"
],
"env": {
"LOG_LEVEL": "DEBUG"
}
}
}
}
(notice the env key, when I added that claude code crashed and overwrote my config 😭 )
I believe this is actually a duplicate of #1788, which we should have fixed in the next release.
@ashwin-ant I don't think it is. #1788 just mentions a reset of MCP config. We are also being logged out and need to reauthenticate. It happened to me AGAIN a few minutes ago. First session of the day.
claude --version 1.0.31 (Claude Code)
Agreed. Also, the problem mentioned is macOS related as far as I understand. I'm experiencing this one on Debian
This absolutely still happens to me too on Ubuntu 25.04
Can you confirm if this tends to happen after modifying the an MCP configuration, or if it's just random?
@ashwin-ant not clear who you're asking. For me it was outside of MCP configuration (I have stopped reconfiguring MCPs as I expect to lose the configuration again)
I'm trying to understand this better. ~/.claude/.mcp.json is not a supported file path for MCP config. The only place where MCP configs are stored currently are ~/.claude.json and .mcp.json in your project directory. It sounds like the issue here is that ~/.claude.json is being reset in some way. If anyone's able to confirm that, that would be very helpful here.
can confirm this issue on ubuntu - has been driving me nuts. Have to log in multiple times per day, and loose all MCP configurations each time. The reset is seemingly random for me. I have stopped utilising MCPs as a result of not wanting to set them up every two hours.
Exactly; the main Claude dotfile config gets replaced and I lose my MCP config and credentials etc, as if I had just installed for the first time.
@ashwin-ant - indeed not the ~/.claude/.mcp.json, just using that as my backup source. but good to know the location of the actual config! that was a mystery to me.
i've copied its contents and will compare / checkout the contents should it happen again. i'm pretty sure it does though if I look at my firstStartTime it says 5 days ago (see screenshot, second arrow).
i'll keep an eye on this file and will update with my findings should it happen again. if you need any other details let me know
Something interesting happened today. I tried to start claude after exiting my terminal (warp) accidentally and it showed my my .claude.json was corrupt (image 1). I looked it up and it showed the mess you in (image 2) at line 2340. Partially duplicated the end of the JSON somehow.
After removing the duplicated partial data it all worked fine.
I'm guessing this is a new mechanic and could be the culprit of previous issues. No idea how it happened though, I haven't touched it anywhere. Perhaps closing the terminal interrupted some kind of update to the file is all I can think of, still weird that it shows double partial data. Either way hope this helps and I'm glad I still have my config.
Hey all, thanks again for the patience here. We believe we have a fix, but we're taking some extra time to make sure we get it right.
I hope so! Just happened again for the first time. I opened a window, typed claude and it somehow launched two instances shortly after each other. I quit because I thought I saw two claude interfaces in one session. Then started it again and I had to choose the theme. I saw these corrupted files in my finder and the .claude.json is pretty much empty.
I found the source issue for me, and implemented an easy fix that seems to have solved it.
When running the local installation, it would attempt an auto update - but would install the update globally rather than locally. This would result in two conflicting versions attempting to run when running "claude"
Running migrate-installer would return "Already running from local installation. No migration needed."
However, upon inspection of .claude.json it was evident that installation method was set to "global"
i corrected it to local, removed the global installation, and no longer have the issue of being logged out every 45 minutes.
Are people still seeing this in 1.0.43? We rolled out a potential fix but please let me know if it's still happening and we can keep working on this.
Hello @ashwin-ant I've actually experienced this for the first time Today after a marathon claude-coding session yesterday. It's possible that the version update with multiple instances open may have actually caused the corrupted .claude.json file.
What would be your suggested approach for recovery? Should I start with a fresh settings file (I've re-logged into my Anthropic account and it has provided a different userID which I find somewhat concerning) or try and fix the .claude.json.corrupted.xxxxxx file?
@kylesnowschwartz - did you confirm your claude --version
@igorkofman I surely did - 1.0.43 (Claude Code) - I have it on auto-update as well. FWIW the claude.json.corrupted file was 20mb large
What happens if you rename claude.json.corrupted to claude.json and launch claude (backup your real claude.json) - it should tell you what failed to parse on launch.
On Mon, Jul 7, 2025 at 2:42 PM kylesnowschwartz @.***> wrote:
kylesnowschwartz left a comment (anthropics/claude-code#1676) https://github.com/anthropics/claude-code/issues/1676#issuecomment-3046597633
@igorkofman https://github.com/igorkofman I surely did - 1.0.43 (Claude Code) - I have it on auto-update as well. FWIW the claude.json.corrupted file was 20mb large
— Reply to this email directly, view it on GitHub https://github.com/anthropics/claude-code/issues/1676#issuecomment-3046597633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADSWQRH3HIJDRYJXKMDUR33HLSTTAVCNFSM6AAAAAB6WPLWC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANBWGU4TONRTGM . You are receiving this because you were mentioned.Message ID: @.***>
Are people still seeing this in 1.0.43? We rolled out a potential fix but please let me know if it's still happening and we can keep working on this.
yes