Skip to content

[BUG] Claude Conversation History Lost on Reconnect Due to Path Resolution #21280

@js-mode

Description

@js-mode

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Bug Report: Conversation History Lost on Reconnect Due to Path Resolution

Summary

Claude Code conversation history disappears when reconnecting VS Code Remote SSH sessions because working directory paths resolve differently across sessions, causing Claude Code to treat each path variation as a separate project.

Environment

  • Claude Model: Claude Sonnet 4.5 (claude-sonnet-4-5-20250929)
  • Claude Code Version: 2.1.20 (linux-x64)
  • VS Code Version: 1.108.2 (commit c9d77990917f3102ada88be140d28b038d1dd7c7)
  • Platform: Linux x64 (QNAP NAS)
  • OS Version: Linux 6.6.32-qnap
  • Connection Type: VS Code Remote SSH
  • Date Reported: 2026-01-27

Problem Description

When disconnecting and reconnecting VS Code Remote SSH to a remote server (QNAP), all Claude Code conversation history disappears and shows blank. This forces users to start over and lose valuable context, wasting significant time.

Root Cause

1. Path Resolution Inconsistency

Claude Code creates project directories based on the resolved working directory path. When the system has symlinks or multiple path representations, different sessions resolve to different paths:

Example paths found in our system:

/share/homes/gin                    (symlink)
/share/ZFS18_DATA/homes/gin        (actual path 1)
/share/ZFS20_DATA/homes/gin        (actual path 2 - different mount?)
/share/ZFS23_DATA/homes/gin        (actual path 3 - different mount?)

Resulting project directories:

~/.claude/projects/
├── -share-ZFS18-DATA-homes-gin/  (436 lines of conversation)
├── -share-ZFS20-DATA-homes-gin/
└── -share-ZFS23-DATA-homes-gin/

Each path variation creates a separate project directory, fragmenting conversation history.

2. TMPDIR Issues

When /tmp fills up or when VS Code tries to use non-existent temporary directories, it may change session paths:

Example error pattern:

/bin/bash: /share/ZFS530_DATA/SuperGin/.vscode-tmp/claude-XXXX-cwd: No such file or directory

This suggests VS Code is creating sessions with different path prefixes based on temp directory availability.

Impact

  • Lost Context: Users lose 40+ message conversations with critical information
  • Wasted Time: Must re-explain context and previous work every reconnection
  • Poor UX: Cannot maintain project continuity across sessions
  • Data Loss Perception: Users think their data is gone (it's not, but it's inaccessible via UI)

Steps to Reproduce

  1. Connect to remote server via VS Code Remote SSH
  2. Start a Claude Code conversation (multiple messages)
  3. Note the current working directory path
  4. Disconnect VS Code
  5. Reconnect VS Code Remote SSH
  6. If the working directory resolves to a different path (e.g., symlink vs actual path), conversation history will be blank

Expected Behavior

Conversation history should persist across reconnections regardless of path representation, using one of these approaches:

  1. Canonical Path Resolution: Always resolve to canonical path (following symlinks)
  2. Path Aliases: Recognize common path variations as the same project
  3. Project ID: Use a stable project identifier beyond just file path
  4. User Prompt: Ask user if detected paths should be merged/linked

Actual Behavior

Each unique resolved path creates a separate project directory, fragmenting conversation history into multiple isolated silos that are invisible to users.

Workarounds Implemented

Fix 1: Force Consistent Path via SSH Config

Host remote-server
    RemoteCommand cd /share/ZFS18_DATA/homes/gin && exec $SHELL -l
    SetEnv TMPDIR=/share/ZFS18_DATA/homes/gin/.vscode-tmp

Fix 2: Fix TMPDIR in .bashrc

export TMPDIR="/share/ZFS18_DATA/homes/gin/.vscode-tmp"
mkdir -p "$TMPDIR" 2>/dev/null

Fix 3: Create Persistent Temp Directory

mkdir -p /share/ZFS18_DATA/homes/gin/.vscode-tmp
chmod 700 /share/ZFS18_DATA/homes/gin/.vscode-tmp

Proposed Solutions

Solution 1: Canonical Path Resolution (Recommended)

Always resolve working directory to its canonical form before creating project directory:

const canonicalPath = fs.realpathSync(workingDirectory);
const projectDir = getProjectDirectory(canonicalPath);

Solution 2: Path Aliasing

Maintain a mapping file of equivalent paths:

{
  "pathAliases": {
    "/share/homes/gin": "/share/ZFS18_DATA/homes/gin",
    "/share/ZFS20_DATA/homes/gin": "/share/ZFS18_DATA/homes/gin"
  }
}

Solution 3: Symlink Detection

When a new project path is detected, check if it resolves to the same inode as an existing project:

const stat1 = fs.statSync(path1);
const stat2 = fs.statSync(path2);
if (stat1.dev === stat2.dev && stat1.ino === stat2.ino) {
  // Same directory, use existing project
}

Solution 4: User Prompt

When a similar path is detected, prompt user:

We detected a new project path: /share/ZFS20_DATA/homes/gin
This appears similar to existing project: /share/ZFS18_DATA/homes/gin

Would you like to:
[ ] Use existing project history
[ ] Create new separate project
[ ] Always treat these paths as the same project

Additional Context

The conversation history files ARE preserved in:

~/.claude/projects/-share-ZFS18-DATA-homes-gin/*.jsonl

But they're not accessible via the UI when the working directory resolves differently. This creates a perception of data loss even though the data exists.

References

Related Issues

This likely affects:

  • Any remote development environment with symlinks
  • Network mounted filesystems
  • Systems with dynamic mount points
  • Docker containers with volume mounts
  • Any environment where path resolution is non-deterministic

Severity

High - Significant UX impact, causes frustration and wasted time for remote development workflows

What Should Happen?

Always resolve working directory to its canonical form before creating project directory. Fix it so that when we reconnect to remote-ssh vscode session, we can see our claude history and previous context. This works fine when using claude agent in vscode-copilot extension, but not with the claude extension directly.

Error Messages/Logs

## Environment
- **Claude Model:** Claude Sonnet 4.5 (`claude-sonnet-4-5-20250929`)
- **Claude Code Version:** 2.1.20 (linux-x64)
- **VS Code Version:** 1.108.2 (commit c9d77990917f3102ada88be140d28b038d1dd7c7)
- **Platform:** Linux x64 (QNAP NAS)
- **OS Version:** Linux 6.6.32-qnap
- **Connection Type:** VS Code Remote SSH
- **Date Reported:** 2026-01-27

Steps to Reproduce

Steps to Reproduce

  1. Connect to remote server via VS Code Remote SSH
  2. Start a Claude Code conversation (multiple messages)
  3. Note the current working directory path
  4. Disconnect VS Code
  5. Reconnect VS Code Remote SSH
  6. If the working directory resolves to a different path (e.g., symlink vs actual path), conversation history will be blank

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.20 (linux-x64)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:idebugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:linuxIssue specifically occurs on LinuxstaleIssue is inactive

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions