›_ Claude Code Issues
Claude Code Issues / #54689

Claude Code reuses the same session-env UUID across sessions on Windows, causing folder-exists failures

Resolved 💬 2 comments Opened Apr 29, 2026 by Buddyboy-git Closed Jun 2, 2026

Preflight Checklist

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

What's Wrong?

Claude Code: Session UUID Reused Across Sessions Instead of Generating Fresh UUID Per Invocation

Environment

  • Claude Code Version: 2.1.81
  • PowerShell Version: 5.1.26100.8115
  • OS: Microsoft Windows 11 Home (Build 10.0.26200.0)
  • Node.js Version: v24.12.0
  • Plan: Claude Max 5x

Description

Claude Code is reusing the same session-env UUID across multiple sessions instead of generating a fresh UUID per session. This causes folder creation failures when the same UUID path already exists and previous cleanup didn't fully complete due to Windows file locking, antivirus scanning, or other lock contention.

Observed Behavior

  1. UUID Persistence: The UUID a508dd3e-a5f5-4c3f-8f66-30fb590a03ed persists across separate Claude Code invocations spanning from April 17 to April 29, 2026
  2. Session Env Folder Contains Multiple UUIDs: Directory listing shows:
  • 7da4765f-c64e-4f3c-8753-a58e6ebe3e76 (4/17/2026 2:11:04 PM)
  • a508dd3e-a5f5-4c3f-8f66-30fb590a03ed (4/29/2026 9:41:18 AM) — still in use 12 days later
  • a8d31aa9-8606-4088-92ed-05ee59f80d7c (4/17/2026 2:24:21 PM)
  1. UUID Pinned in Project Configuration: The problematic UUID appears in multiple project history files and session logs:
  • .claude\file-history\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed\ (multiple indexed session records)
  • .claude\file-history\d9191e92-8674-49cb-b283-a48143264e10\ (cross-session file references linking back to the same UUID)
  • .claude\projects\d--xampp-htdocs-orderthing\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed.jsonl (entire session history stored under this UUID)
  1. Session History Locked Under UUID: The JSONL file contains a complete 12-day conversation history with timestamps from 2026-04-17T17:49:48.181Z onwards, indicating this UUID was assigned once and never regenerated.

Expected Behavior

  • Each Claude Code session should generate a new random UUID
  • Session environment folders should not collide across separate invocations
  • Cleanup should reliably remove session state without folder-exists contention
  • Old session UUIDs should eventually be garbage-collected or managed per-session, not persisted indefinitely

Steps to Reproduce

  1. Start a Claude Code session and note the session-env UUID (visible in cleanup commands)
  2. Run multiple Claude Code commands across different days
  3. Check C:\Users\<USER>\.claude\session-env\ — confirm the same UUID appears in cleanup attempts
  4. Search C:\Users\<USER>\.claude\ for the UUID string — find it pinned in:
  • .claude\file-history\<UUID>\ (multiple entries)
  • .claude\projects\<hash>\<UUID>.jsonl
  1. Inspect the JSONL file — find session history spanning multiple days/invocations under the same UUID

Root Cause Hypothesis

The UUID is being assigned once (likely per-project or per-user) and reused for all subsequent sessions within that scope, rather than being randomly generated on each claude invocation. The session ID generation logic likely:

  1. Checks for an existing UUID in project configuration (.claude/projects/<hash>/ metadata)
  2. If found, reuses it
  3. If not found, generates a new one
  4. Stores it in project metadata for "session continuity"

This causes:

  • Session folder accumulation: Old folders (from older UUIDs) are left orphaned but not cleaned up
  • Lock contention: Windows can't delete or recreate the same folder in quick succession
  • Antivirus interference: Scanning delays prevent cleanup from completing before the next session tries to use the same path

Evidence from Diagnostic Data

File-History Cross-Linking

Multiple file entries reference the same session UUID across different file histories, suggesting all file operations are being tagged with a single persistent ID rather than per-session IDs.

Project JSONL Session Log

The file .claude\projects\d--xampp-htdocs-orderthing\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed.jsonl contains:

  • Queue operations (enqueue/dequeue) timestamped April 17, 2026
  • User message "try again" with full sessionId: a508dd3e-a5f5-4c3f-8f66-30fb590a03ed
  • Full LLM responses with model version 2.1.112 and the same sessionId
  • All entries tagged with the same sessionId across multiple days

This indicates the entire session history for this project is stored under a single, persistent session ID.

Impact

  • Disk space: Session folders accumulate without cleanup, consuming disk space
  • Reliability: Race conditions between concurrent cleanup and new session creation
  • Performance: File locking can delay or fail session initialization
  • Developer Experience: Mysterious "folder already exists" errors when Windows AV is active

Additional Context

  • Claude Code Remote Control is in use (may be relevant to session ID persistence)
  • Typical invocations use --dangerously-skip-permissions flag
  • OrderThing project shows the most clear evidence of UUID reuse across 12 days of use

Recommended Fix

  1. Generate a truly unique session ID per-invocation (UUID v4 or timestamp-based)
  2. Do not store session IDs in project metadata for reuse
  3. Implement proper session cleanup with retry logic (handle Windows file locks)
  4. Add garbage collection for orphaned session-env folders after N days
  5. Log session ID assignment at startup for debugging

---

Issue Type: Bug
Priority: Medium (workaround: manual cleanup possible)
Affects: Windows systems with file locking, antivirus scanning

What Should Happen?

Claude Code: Session UUID Reused Across Sessions Instead of Generating Fresh UUID Per Invocation

Environment

  • Claude Code Version: 2.1.81
  • PowerShell Version: 5.1.26100.8115
  • OS: Microsoft Windows 11 Home (Build 10.0.26200.0)
  • Node.js Version: v24.12.0
  • Plan: Claude Max 5x

Description

Claude Code is reusing the same session-env UUID across multiple sessions instead of generating a fresh UUID per session. This causes folder creation failures when the same UUID path already exists and previous cleanup didn't fully complete due to Windows file locking, antivirus scanning, or other lock contention.

Observed Behavior

  1. UUID Persistence: The UUID a508dd3e-a5f5-4c3f-8f66-30fb590a03ed persists across separate Claude Code invocations spanning from April 17 to April 29, 2026
  2. Session Env Folder Contains Multiple UUIDs: Directory listing shows:
  • 7da4765f-c64e-4f3c-8753-a58e6ebe3e76 (4/17/2026 2:11:04 PM)
  • a508dd3e-a5f5-4c3f-8f66-30fb590a03ed (4/29/2026 9:41:18 AM) — still in use 12 days later
  • a8d31aa9-8606-4088-92ed-05ee59f80d7c (4/17/2026 2:24:21 PM)
  1. UUID Pinned in Project Configuration: The problematic UUID appears in multiple project history files and session logs:
  • .claude\file-history\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed\ (multiple indexed session records)
  • .claude\file-history\d9191e92-8674-49cb-b283-a48143264e10\ (cross-session file references linking back to the same UUID)
  • .claude\projects\d--xampp-htdocs-orderthing\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed.jsonl (entire session history stored under this UUID)
  1. Session History Locked Under UUID: The JSONL file contains a complete 12-day conversation history with timestamps from 2026-04-17T17:49:48.181Z onwards, indicating this UUID was assigned once and never regenerated.

Expected Behavior

  • Each Claude Code session should generate a new random UUID
  • Session environment folders should not collide across separate invocations
  • Cleanup should reliably remove session state without folder-exists contention
  • Old session UUIDs should eventually be garbage-collected or managed per-session, not persisted indefinitely

Steps to Reproduce

  1. Start a Claude Code session and note the session-env UUID (visible in cleanup commands)
  2. Run multiple Claude Code commands across different days
  3. Check C:\Users\<USER>\.claude\session-env\ — confirm the same UUID appears in cleanup attempts
  4. Search C:\Users\<USER>\.claude\ for the UUID string — find it pinned in:
  • .claude\file-history\<UUID>\ (multiple entries)
  • .claude\projects\<hash>\<UUID>.jsonl
  1. Inspect the JSONL file — find session history spanning multiple days/invocations under the same UUID

Root Cause Hypothesis

The UUID is being assigned once (likely per-project or per-user) and reused for all subsequent sessions within that scope, rather than being randomly generated on each claude invocation. The session ID generation logic likely:

  1. Checks for an existing UUID in project configuration (.claude/projects/<hash>/ metadata)
  2. If found, reuses it
  3. If not found, generates a new one
  4. Stores it in project metadata for "session continuity"

This causes:

  • Session folder accumulation: Old folders (from older UUIDs) are left orphaned but not cleaned up
  • Lock contention: Windows can't delete or recreate the same folder in quick succession
  • Antivirus interference: Scanning delays prevent cleanup from completing before the next session tries to use the same path

Evidence from Diagnostic Data

File-History Cross-Linking

Multiple file entries reference the same session UUID across different file histories, suggesting all file operations are being tagged with a single persistent ID rather than per-session IDs.

Project JSONL Session Log

The file .claude\projects\d--xampp-htdocs-orderthing\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed.jsonl contains:

  • Queue operations (enqueue/dequeue) timestamped April 17, 2026
  • User message "try again" with full sessionId: a508dd3e-a5f5-4c3f-8f66-30fb590a03ed
  • Full LLM responses with model version 2.1.112 and the same sessionId
  • All entries tagged with the same sessionId across multiple days

This indicates the entire session history for this project is stored under a single, persistent session ID.

Impact

  • Disk space: Session folders accumulate without cleanup, consuming disk space
  • Reliability: Race conditions between concurrent cleanup and new session creation
  • Performance: File locking can delay or fail session initialization
  • Developer Experience: Mysterious "folder already exists" errors when Windows AV is active

Additional Context

  • Claude Code Remote Control is in use (may be relevant to session ID persistence)
  • Typical invocations use --dangerously-skip-permissions flag
  • OrderThing project shows the most clear evidence of UUID reuse across 12 days of use

Recommended Fix

  1. Generate a truly unique session ID per-invocation (UUID v4 or timestamp-based)
  2. Do not store session IDs in project metadata for reuse
  3. Implement proper session cleanup with retry logic (handle Windows file locks)
  4. Add garbage collection for orphaned session-env folders after N days
  5. Log session ID assignment at startup for debugging

---

Issue Type: Bug
Priority: Medium (workaround: manual cleanup possible)
Affects: Windows systems with file locking, antivirus scanning

Error Messages/Logs

Steps to Reproduce

Claude Code: Session UUID Reused Across Sessions Instead of Generating Fresh UUID Per Invocation

Environment

  • Claude Code Version: 2.1.81
  • PowerShell Version: 5.1.26100.8115
  • OS: Microsoft Windows 11 Home (Build 10.0.26200.0)
  • Node.js Version: v24.12.0
  • Plan: Claude Max 5x

Description

Claude Code is reusing the same session-env UUID across multiple sessions instead of generating a fresh UUID per session. This causes folder creation failures when the same UUID path already exists and previous cleanup didn't fully complete due to Windows file locking, antivirus scanning, or other lock contention.

Observed Behavior

  1. UUID Persistence: The UUID a508dd3e-a5f5-4c3f-8f66-30fb590a03ed persists across separate Claude Code invocations spanning from April 17 to April 29, 2026
  2. Session Env Folder Contains Multiple UUIDs: Directory listing shows:
  • 7da4765f-c64e-4f3c-8753-a58e6ebe3e76 (4/17/2026 2:11:04 PM)
  • a508dd3e-a5f5-4c3f-8f66-30fb590a03ed (4/29/2026 9:41:18 AM) — still in use 12 days later
  • a8d31aa9-8606-4088-92ed-05ee59f80d7c (4/17/2026 2:24:21 PM)
  1. UUID Pinned in Project Configuration: The problematic UUID appears in multiple project history files and session logs:
  • .claude\file-history\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed\ (multiple indexed session records)
  • .claude\file-history\d9191e92-8674-49cb-b283-a48143264e10\ (cross-session file references linking back to the same UUID)
  • .claude\projects\d--xampp-htdocs-orderthing\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed.jsonl (entire session history stored under this UUID)
  1. Session History Locked Under UUID: The JSONL file contains a complete 12-day conversation history with timestamps from 2026-04-17T17:49:48.181Z onwards, indicating this UUID was assigned once and never regenerated.

Expected Behavior

  • Each Claude Code session should generate a new random UUID
  • Session environment folders should not collide across separate invocations
  • Cleanup should reliably remove session state without folder-exists contention
  • Old session UUIDs should eventually be garbage-collected or managed per-session, not persisted indefinitely

Steps to Reproduce

  1. Start a Claude Code session and note the session-env UUID (visible in cleanup commands)
  2. Run multiple Claude Code commands across different days
  3. Check C:\Users\<USER>\.claude\session-env\ — confirm the same UUID appears in cleanup attempts
  4. Search C:\Users\<USER>\.claude\ for the UUID string — find it pinned in:
  • .claude\file-history\<UUID>\ (multiple entries)
  • .claude\projects\<hash>\<UUID>.jsonl
  1. Inspect the JSONL file — find session history spanning multiple days/invocations under the same UUID

Root Cause Hypothesis

The UUID is being assigned once (likely per-project or per-user) and reused for all subsequent sessions within that scope, rather than being randomly generated on each claude invocation. The session ID generation logic likely:

  1. Checks for an existing UUID in project configuration (.claude/projects/<hash>/ metadata)
  2. If found, reuses it
  3. If not found, generates a new one
  4. Stores it in project metadata for "session continuity"

This causes:

  • Session folder accumulation: Old folders (from older UUIDs) are left orphaned but not cleaned up
  • Lock contention: Windows can't delete or recreate the same folder in quick succession
  • Antivirus interference: Scanning delays prevent cleanup from completing before the next session tries to use the same path

Evidence from Diagnostic Data

File-History Cross-Linking

Multiple file entries reference the same session UUID across different file histories, suggesting all file operations are being tagged with a single persistent ID rather than per-session IDs.

Project JSONL Session Log

The file .claude\projects\d--xampp-htdocs-orderthing\a508dd3e-a5f5-4c3f-8f66-30fb590a03ed.jsonl contains:

  • Queue operations (enqueue/dequeue) timestamped April 17, 2026
  • User message "try again" with full sessionId: a508dd3e-a5f5-4c3f-8f66-30fb590a03ed
  • Full LLM responses with model version 2.1.112 and the same sessionId
  • All entries tagged with the same sessionId across multiple days

This indicates the entire session history for this project is stored under a single, persistent session ID.

Impact

  • Disk space: Session folders accumulate without cleanup, consuming disk space
  • Reliability: Race conditions between concurrent cleanup and new session creation
  • Performance: File locking can delay or fail session initialization
  • Developer Experience: Mysterious "folder already exists" errors when Windows AV is active

Additional Context

  • Claude Code Remote Control is in use (may be relevant to session ID persistence)
  • Typical invocations use --dangerously-skip-permissions flag
  • OrderThing project shows the most clear evidence of UUID reuse across 12 days of use

Recommended Fix

  1. Generate a truly unique session ID per-invocation (UUID v4 or timestamp-based)
  2. Do not store session IDs in project metadata for reuse
  3. Implement proper session cleanup with retry logic (handle Windows file locks)
  4. Add garbage collection for orphaned session-env folders after N days
  5. Log session ID assignment at startup for debugging

---

Issue Type: Bug
Priority: Medium (workaround: manual cleanup possible)
Affects: Windows systems with file locking, antivirus scanning

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.81

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗