OpenClaw Fails to Resolve File Paths and Filenames with Mixed Chinese/English/Numeric Characters

[humble fjord]

Current Issue:
OpenClaw fails to read files under the following two scenarios related to path and filename encoding:

Mixed-character directory names: Any folder in the path contains a mix of Chinese and English characters, or Chinese characters and digits.

Mixed-character filenames: The target filename itself contains a mix of Chinese and English characters, or Chinese characters and digits.

Hardware: Mac mini (M4 Pro), 64GB Unified Memory

OpenClaw Version: 2026.03.28

Primary Model: Qwen 3.5 35B (4-bit quantization)

Inference Framework: MLX (via oMLX)

OS: macOS (latest Version)

hello Krill？

[crystal acorn]

Hey Bigbear — I’m here 👋

Thanks for the clear bug report. This does sound like a real Windows encoding/path handling edge case (especially with mixed CJK + ASCII/digits).

Can you paste these first so I can pin it down fast:

1. openclaw --version
2. openclaw status --all
3. One exact failing example:

• tool/command used (read / exec / etc.)
• exact path string
• exact error text

If you’re on native Windows + PowerShell/Git Bash, also try the FAQ UTF-8 workaround, then restart gateway:

chcp 65001
[Console]::InputEncoding = [System.Text.UTF8Encoding]::new($false)
[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false)
$OutputEncoding = [System.Text.UTF8Encoding]::new($false)
openclaw gateway restart

Docs:

• FAQ: https://docs.openclaw.ai/help/faq
• Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

If this still reproduces on latest version, please file a GitHub bug with your repro matrix (I can help you format it):
https://github.com/openclaw/openclaw/issues

[humble fjord]

I’ve conducted a controlled comparison on my Mac mini (M4 Pro). The results clearly show that OpenClaw's read tool fails specifically when Chinese characters are mixed with English/Digits in either the folder name or the filename.

1. Success Cases (Pure English or Pure Chinese structure):

'/Volumes/P31 2T/OpenClaw_Workspace/test.pdf' → SUCCESS

/Users/bigbearccc/Downloads/其他/检查文档.txt → SUCCESS (Pure Chinese folder + Pure Chinese filename works)

2. Failure Cases (Mixed Characters/Digits):

'/Volumes/P31 2T/OpenClaw_Workspace/测试test.pdf' → FAIL (Mixed Chinese + English filename)

/Users/bigbearccc/Downloads/其他test/检查文档.txt → FAIL (Mixed Chinese + English folder name)

3. Diagnostic Error (from openclaw status --all):
   The logs consistently report ENOENT: no such file or directory for these mixed-character paths.
   Example: access '/Volumes/P31 2T/.openclaw/workspace/瑞源公司员工手册 2016 版.pdf'

[crystal acorn]

This is super helpful — thank you for the clean A/B test. 🙏

Your log clue is the key one:

ENOENT ... '/Volumes/P31 2T/.openclaw/workspace/瑞源公司员工手册 2016 版.pdf'

That means read is trying inside the workspace root, not the original absolute path you typed.
So this looks less like macOS UTF-8 filesystem failure, and more like path argument resolution/parsing before read executes.

Can you share just 2 more artifacts?

1. The exact tool-call payload line for a failing case (the read input JSON, especially path)
2. openclaw --version

Also please test this exact form once (no single quotes around path, and force absolute with @):

• @/Volumes/P31 2T/OpenClaw_Workspace/测试test.pdf
• @/Users/bigbearccc/Downloads/其他test/检查文档.txt

And check whether workspace restriction is enabled:

• openclaw config get tools.fs.workspaceOnly

---

Temporary workaround (until fixed)

• Put/symlink target files under the current workspace and read via relative path from workspace.
• Or keep using pure-relative paths inside workspace only.

If this still reproduces on latest, please file it as a bug (this looks legit):
https://github.com/openclaw/openclaw/issues

If you paste the 2 artifacts above, I’ll help you draft a perfect issue body so maintainers can reproduce immediately.

[humble fjord]

Let's clear the confusion. The ENOENT log you saw for the "Employee Handbook" was just one specific failed attempt. My A/B test with the following paths proves a different point:

1. The "Pure" Success (Absolute paths work fine):

/Users/bigbearccc/Downloads/其他/检查文档.txt -> SUCCESS

(This proves absolute paths outside the workspace DO work if they are pure Chinese or pure English).

2. The "Mixed-Character" Failure (Same absolute logic, but fails):

/Users/bigbearccc/Downloads/其他test/检查文档.txt -> FAIL

(The only difference here is the "test" suffix added to a Chinese folder name).

The Core Issue:
It’s not that OpenClaw is "misplacing" the files into the workspace. It’s that when a single string contains a mix of CJK (Chinese) + ASCII (English/Digits), the underlying tool call fails to resolve the path correctly on macOS.

3. Requested Info:

openclaw --version: 2026.3.28

tools.fs.workspaceOnly: false (I can read absolute paths, just not "mixed-character" ones).

Payload Insight: When the model calls read, the JSON path string looks correct, but the system returns ENOENT.

My Hypothesis:
Since I'm on macOS (M4 Pro), this is likely a Normalization (NFC/NFD) mismatch triggered specifically by mixed-character strings during the string-to-binary conversion in the read tool.

hello bro？！

https://tenor.com/view/waiting-still-gif-20331665

[crystal acorn]

You’re right — and thanks for the patience. Your repro is solid. ✅

Given your data:

• openclaw --version: 2026.3.28
• tools.fs.workspaceOnly: false
• absolute pure path works
• absolute mixed CJK+ASCII path fails with ENOENT

…this is a legit bug, likely in read-path normalization/resolution on macOS (not just workspace routing).

Fastest next step

Please open a GitHub issue with your exact A/B matrix (this is exactly the kind of report maintainers can act on):
https://github.com/openclaw/openclaw/issues

If useful, paste this as the core repro block: