[BUG] File path autocomplete displays Chinese characters as octal escape sequences in v2.0.73

Status Fixed / completed
Reported on v2.0.74
Maintainer reply None cached
Activity 3 comments · opened Dec 20, 2025 · closed Jan 15, 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?

When using the @ symbol to reference files in Claude Code CLI, file paths containing Chinese characters are displayed as octal escape sequences instead of the actual Chinese characters in the autocomplete dropdown list.

For example, a file path like:
中文文字檔案.pdf

Is displayed as:
\344\270\255\346\226\207\345\255\227\346\252\224\346\241\210.pdf

What Should Happen?

File paths should display Chinese characters properly in the autocomplete dropdown list, making it easy to identify and select the correct file.

Error Messages/Logs

Steps to Reproduce

  1. Navigate to a project directory containing files or folders with Chinese characters in their paths
  2. Type @ in the Claude Code prompt to trigger file reference/autocomplete
  3. Observe the file path suggestions in the dropdown list
  4. Chinese characters appear as octal escape sequences (e.g., \345\234\221 instead of 國)

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.0.72

Claude Code Version

2.0.74

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

  • The octal sequences are valid UTF-8 byte representations of Chinese characters

For example: \345\234\221 is the UTF-8 encoding of the character "國"

  • File operations work correctly; this is purely a display issue in the autocomplete UI
  • This significantly impacts usability for users working with projects that have Chinese filenames or paths
  • The issue first appeared in version 2.0.73 and persists through version 2.0.74
  • macOS version: Darwin 24.6.0

View original on GitHub ↗

3 Comments

whjstc · 7 months ago

Workaround Found: Configure Git to Display UTF-8 Characters

I encountered the same issue with Chinese characters displaying as octal sequences in the @ autocomplete. I found a workaround that fixes the display issue:

git config --global core.quotePath false

Why this works:

Claude Code's @ file autocomplete appears to rely on Git commands (like git ls-files or git status) to list files. By default, Git escapes non-ASCII characters in file paths. Setting core.quotePath to false tells Git to output raw UTF-8 characters instead of octal escape sequences.

Before:

\345\256\236\347\224\250 Claude Code Skills \346\216\250\350\215\220\346\270\205\345\215\225.md

After:

實用 Claude Code Skills 推薦清單.md

Additional recommendation:

If you're still seeing issues, ensure your shell locale is set to UTF-8:

# Add to ~/.zshrc or ~/.bashrc
export LANG=zh_TW.UTF-8  # For Traditional Chinese
export LC_ALL=zh_TW.UTF-8

Then restart your terminal or run source ~/.zshrc.

---

找到臨時解決方案:配置 Git 顯示 UTF-8 字符

我遇到了同樣的問題,中文字符在 @ 自動補全中顯示為八進制序列。我找到了一個可以修復顯示問題的臨時方案:

git config --global core.quotePath false

為什麼這個方案有效:

Claude Code 的 @ 文件自動補全似乎依賴 Git 命令(如 git ls-filesgit status)來列出文件。默認情況下,Git 會轉義文件路徑中的非 ASCII 字符。將 core.quotePath 設置為 false 可以讓 Git 輸出原始的 UTF-8 字符,而不是八進制轉義序列。

修改前:

\345\256\236\347\224\250 Claude Code Skills \346\216\250\350\215\220\346\270\205\345\215\225.md

修改後:

實用 Claude Code Skills 推薦清單.md

額外建議:

如果仍然有問題,請確保您的 shell locale 設置為 UTF-8:

# 添加到 ~/.zshrc 或 ~/.bashrc
export LANG=zh_TW.UTF-8  # 繁體中文
export LC_ALL=zh_TW.UTF-8

然後重啟終端或運行 source ~/.zshrc

---

This is a workaround, not a fix for the underlying TUI bug, but it makes Claude Code usable with Chinese filenames again.

Tested on:

  • macOS 14.6 (Darwin 24.6.0)
  • Claude Code 2.0.74
  • Both Simplified Chinese (zh_CN) and Traditional Chinese (zh_TW) filenames
ryuki0724 · 7 months ago

感謝大大,這問題解決了!

github-actions[bot] · 7 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.