Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Session resume fails on macOS case-insensitive filesystem when path casing differs [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48645•Fetched 2026-04-16 06:54:49
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
mblevinmblevin
Participants
mblevinmblevin
Timeline (top)
labeled ×3closed ×1renamed ×1reopened ×1

Fix Action

Fix / Workaround

Workaround: Rename the project directory under ~/.claude/projects/ to match the casing your shell resolves (requires a two-step mv on case-insensitive FS since direct case-only renames don't work).

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • I am using the latest version of Claude Code

What's Wrong?

claude --resume shows "no sessions to resume" when the working directory path casing differs from when sessions were originally created. For example, launching from ~/Projects/my-repo creates sessions, but resuming from ~/projects/my-repo finds nothing.

On macOS (APFS, case-insensitive by default), these are the same directory (same inode). Claude Code generates the project storage key from the literal path string, preserving casing:

  • ~/Projects/repo → -Users-me-Projects-repo
  • ~/projects/repo → -Users-me-projects-repo

Session lookup does a case-sensitive match against the key, so sessions filed under one casing are invisible when launching from the other. The session files are all present on disk — the bug is purely in the key lookup logic.

This also affects project-scoped memory and settings under ~/.claude/projects/.

What Should Happen?

claude --resume should find sessions regardless of path casing on case-insensitive filesystems. Both ~/Projects/repo and ~/projects/repo should resolve to the same project key.

Steps to Reproduce

  1. mkdir -p ~/Projects/test-repo && cd ~/Projects/test-repo && git init
  2. Run claude, have a conversation, exit
  3. cd ~/projects/test-repo (lowercase p — same directory on case-insensitive FS)
  4. claude --resume
  5. Result: "No sessions to resume"

You can verify it's the same directory: stat -f "%i" ~/Projects ~/projects returns the same inode.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.92 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Suggested fix: Normalize the working directory to a canonical form before generating the project storage key. Options:

  • fs.realpathSync() (resolves symlinks + canonical casing)
  • Lowercase the path on case-insensitive filesystems
  • Compare by inode/device ID instead of path string

Workaround: Rename the project directory under ~/.claude/projects/ to match the casing your shell resolves (requires a two-step mv on case-insensitive FS since direct case-only renames don't work).

extent analysis

TL;DR

Normalize the working directory path to a canonical form before generating the project storage key to fix the case sensitivity issue.

Guidance

  • Use fs.realpathSync() to resolve symlinks and canonical casing for the working directory path.
  • Consider lowercasing the path on case-insensitive filesystems as an alternative solution.
  • Verify the fix by running claude --resume from different casing variations of the project directory and checking that sessions are correctly resumed.
  • To mitigate the issue temporarily, rename the project directory under ~/.claude/projects/ to match the casing resolved by the shell, using a two-step mv process on case-insensitive filesystems.

Example

const fs = require('fs');
const path = require('path');

// Normalize the working directory path
const normalizedPath = fs.realpathSync(path.resolve('.'));

Notes

The provided fs.realpathSync() suggestion assumes a Node.js environment, which may not be the case for Claude Code. The actual implementation should be adapted to the programming language and environment used by Claude Code.

Recommendation

Apply the workaround by normalizing the working directory path, as it directly addresses the root cause of the issue and provides a clear solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING