### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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's path encoding for session storage replaces all non-Latin characters with hyphens. For example: `C:\Users\...\Desktop\测试中文目录` is encoded a

Path encoding strips all non-Latin characters — different directories collide, sessions cross-project visible, cleanup causes data loss

Status Closed — duplicate

Reported on v2.1.190

Maintainer reply None cached

Activity 5 comments · opened Jun 24, 2026 · closed Aug 20, 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's path encoding for session storage replaces all non-Latin characters with hyphens.

For example: C:\Users\...\Desktop\测试中文目录 is encoded as C--Users-...-Desktop------- — all 6 Chinese
characters become 6 hyphens.

This means two different directories with the same number of non-Latin characters map to the SAME .claude/projects/
directory. Sessions from both directories are stored together, visible to each other, and deleted together during
cleanup.

Confirmed across 4 languages: Chinese (测试中文目录), Japanese (日本語テスト), Korean (한국어테스트), Arabic
.)رابتخا(

Impact chain (6 layers discovered, all from the same root cause):

Non-Latin characters → hyphens: All CJK/non-Latin characters stripped.
Directory collision: Different dirs with same char count → same session dir.
Cross-project data loss: claude project purge in directory A deletes directory B's sessions.
Cross-project session visibility: --resume in directory B shows directory A's conversations.
Pre-existing collisions: Reporter's own system already has 5 hyphen-only entries with sessions from real

directories, e.g. C--Users-...-Desktop-------- contains sessions from C:\Users\...\Desktop\资料.

Trust state separation: .claude.json stores trust by real path (separate), but sessions by encoded path

(collided). "Don't ask again" permissions in one directory apply to the collided directory.

Detection tool created: https://github.com/yurenpai/ai-config-guard (NON_LATIN_DIRNAME rule)

What Should Happen?

Claude Code should preserve the full directory name in path encoding so that:

Different directories always map to different .claude/projects/ entries — regardless of language or character

set.

claude project purge only deletes sessions from the specific directory where it was run — not from unrelated

directories that happen to have the same non-Latin character count.

--resume only shows sessions from the current directory — not from other directories that collided via encoding.

All languages (Chinese, Japanese, Korean, Arabic, Russian, Hebrew, Thai, and any other non-Latin script) are

handled identically to Latin-script directory names.

Suggested fix: Use URL-encoding, Base64, or a hash of the full path — rather than stripping non-Latin characters.

Error Messages/Logs

No error messages, warnings, or log entries are produced at any stage:

  - Directory encoding: Silent. No indication the path was modified.
  - Session collision: Silent. No warning that two directories share a session directory.
  - `claude project purge`: No warning that sessions from other directories will also be deleted.
  - `--resume`: No indication that displayed sessions originate from a different directory.
  - `.claude/projects/`: No validation that encoded directory names are unique.

  The only way to detect the issue is manual inspection of `.claude/projects/` directory names or use of a detection
  tool.

Steps to Reproduce

Create two directories with the same number of non-Latin characters:

mkdir C:\Users\...\Desktop\项目甲
mkdir C:\Users\...\Desktop\测试乙

Run claude "hello" in each directory.

Observe .claude/projects/ — both sessions stored in the same directory:

C--Users-...-Desktop----

Run claude project purge from 项目甲 — confirm deletion.

Run claude --resume from 测试乙 — no conversations found (deleted by step 4).

Reproduce the collision with other non-Latin languages:

Japanese: 日本語テスト
Korean: 한국어테스트
Arabic: رابتخا

All produce identical collision behavior.

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.190

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Also confirmed on version 2.1.186 before auto-update. Detection tool:
https://github.com/yurenpai/ai-config-guard

View original on GitHub ↗

3 Comments

AlexQuaken · 1 month ago

Confirming this on Windows 11 with Cyrillic folder names.

The project slug is derived from the working directory via a lossy
substitution: every non-[A-Za-z0-9] character (path separators, colon,
space, dot, and all non-Latin letters) is replaced by a single "-".

Two consequences follow, and both are more than cosmetic:

Collision / lost data. Any two sibling folders whose names differ only

in non-Latin content but have the same character count map to an
identical slug. Their sessions land in the same ~/.claude/projects
directory, so /resume in one project lists the other project's
conversations, token/cost stats are merged, and a purge in one can
delete the other's history. On a machine with several Cyrillic-named
projects this is not hypothetical — the encoded folder name becomes a
pure run of dashes shared by multiple real directories.

Separators are indistinguishable from content. Because "\", "-", "_",

"." and non-Latin letters all collapse to the same "-", the encoding is
not reversible. Third-party tools that read ~/.claude/projects and try
to reconstruct the original path (session viewers, resume helpers)
cannot tell a path separator from a dash that used to be a letter, so
they render phantom nesting and wrong project trees.

Expected: a reversible, collision-free encoding — percent-encoding
(RFC 3986) or preserving Unicode directly, since modern filesystems
handle it. At minimum, non-Latin codepoints should be encoded losslessly
rather than all mapped to one "-".

Environment: Claude Code on Windows 11.

vianne75-crypto · 1 month ago

Confirming this on macOS (Claude Code VSCode extension), which extends the affected-platform list beyond Windows.

Repro: two sibling project directories, each with a 3-character Korean name (e.g. ~/work/디자인 and ~/work/웹운영), collide to the identical ~/.claude/projects/<slug> folder since both names encode to the same run of hyphens.

New angle not yet covered here: this surfaces directly in the Claude Code VSCode extension's UI, not just the CLI. The extension's session sidebar mixes sessions from both real projects into one list, and the tab-title project-name prefix for the same session inconsistently renders as either directory's name depending on render context — because the extension resolves the label from the collided slug bucket rather than the session's own recorded cwd. This makes it impossible for a user managing multiple projects/agents through the extension to reliably tell which project a listed session belongs to from the UI alone — you have to grep the raw jsonl cwd field to find out for sure.

+1 for percent-encoding or otherwise preserving Unicode losslessly in the slug, as suggested above — the current behavior is silently unsafe for any non-Latin-named project directories, and the failure mode (session/history cross-contamination between unrelated projects) is easy to miss until it causes real confusion or data loss.

yurenpai · 26 days ago

Thanks for confirming and adding more repro cases.

This makes the scope clearer:

Windows 11 + Cyrillic folder names reproduce the same collision.
macOS + Korean folder names reproduce the same collision.
The issue affects both CLI session storage and the Claude Code VSCode extension UI.

So this appears to be a general lossy path-slug encoding issue for non-Latin / non-ASCII project paths, not a Chinese-specific or Windows-specific bug.

A lossless / collision-resistant encoding, such as percent-encoding, base64url, or a stable hash of the full path, should avoid these collisions. Existing collided ~/.claude/projects folders may also need migration or compatibility handling.

Showing cached comments. Read the full discussion on GitHub ↗