fix: handle non-ASCII filenames in file send

[kyan-du]

Problem

Sending files with non-ASCII filenames (e.g. CJK characters like 遗憾-注释版.pdf) via the /api/messages/send endpoint silently fails — the API returns {"success": true} but the file is never actually sent through WeChat.

Root Cause

Two separate issues:

1. paste-file script: raw non-ASCII bytes in file:// URI

The script builds a file:// URI from the absolute path and passes it to xclip. When the path contains non-ASCII characters (CJK, etc.), WeChat's Qt under POSIX locale cannot resolve the URI, so the clipboard paste silently does nothing.

2. messages.rs: silent failure on file write/decode errors

If base64::decode or std::fs::write fails, file_path remains None. The handler then runs the send plan with no file, finishes successfully, and returns {"success": true} — even though nothing was sent.

Fix

docker/tools/paste-file

• Detect non-ASCII characters in the resolved path
• Copy the file to an ASCII-safe temp path (/tmp/paste_safe_<timestamp>.<ext>)
• Use the safe path for the file:// URI
• Schedule cleanup after 10 seconds (gives WeChat time to read)

packages/agent-server-rust/src/router/messages.rs

• Sanitize the filename to ASCII (replace non-alphanumeric/non-ASCII chars with _) for the temp path
• Return proper error responses (success: false + error message) when base64 decode or file write fails, instead of silently succeeding

Testing

Verified on agent-wechat 0.11.12 (Docker, linux-arm64):

Filename	Before	After
test.pdf (ASCII)	✅ Sent	✅ Sent
遗憾-注释版.pdf (CJK)	❌ Silent fail	✅ Sent
中文测试.pdf (CJK)	❌ Silent fail	✅ Sent

[thisnick]

Good fix — both issues are real and the approach is sound. A few notes:

docker/tools/paste-file

The grep -qP '[^\x00-\x7F]' pattern requires grep with PCRE support (-P). GNU grep has it but some minimal Docker base images ship BusyBox grep which doesn't. Consider using a portable alternative:

# Portable: checks if path survives ASCII round-trip
if [ "$ABS_PATH" != "$(echo "$ABS_PATH" | LC_ALL=C tr -cd '\\0-\\177')" ]; then

Or just check the exit code of iconv:

if ! echo "$ABS_PATH" | iconv -f UTF-8 -t ASCII >/dev/null 2>&1; then

The 10-second cleanup window is probably fine for normal use, but a large file paste could theoretically race. Not blocking — just worth noting.

messages.rs

The error handling improvement is a clear win. One minor nit: the safe_name mapping strips the extension separator dot along with CJK chars if the original filename has a CJK stem + ASCII extension (e.g. 遗憾.pdf → ____.pdf). That's fine functionally since it's a temp path, but worth a comment clarifying intent.

Changeset

Please add a changeset for this fix so it gets picked up in the next release:

npx changeset

Select patch for agent-server-rust (and whichever package owns paste-file if it's versioned separately). Add a brief description matching the PR title.

[thisnick]

(Apologies for the duplicate review comments above — please refer to the last one only.)

[kyan-du]

Thanks for the review! Addressed all three points:

1. paste-file: Replaced grep -qP with the portable iconv check you suggested — works on BusyBox/minimal images too.

2. messages.rs: Added a comment clarifying that the dot is preserved intentionally (so file extensions survive) and the mangled stem is acceptable for transient temp paths.

3. Changeset: Added patch changeset for @agent-wechat/agent-server.

Pushed in 5b8ef39.