Summary

On Windows 11, exec command output can be rendered as mojibake when it is routed back into chat through OpenClaw system messages (Exec finished / Exec completed / Exec failed), even when the underlying file content is valid UTF-8.

This appears related to, but not identical with, #5113.

Environment

• OS: Windows 11
• OpenClaw runtime observed: 2026.2.22
• Config had previously been written by: 2026.2.24
• Shells involved: Windows PowerShell 5.1, PowerShell 7
• Channel/UI: Control UI / in-chat system event rendering

What happens

Commands that touch or print Chinese text can succeed, but the result echoed back into chat as a system event becomes garbled.

Examples observed in chat/system messages:

• System: ... Exec finished ...
• System: ... Exec completed ...
• System: ... Exec failed ...

The garbled text often comes from command output that includes Chinese documentation paths or Chinese text snippets.

Important detail

This does not look like simple file corruption:

• Daily memory files were verified as valid UTF-8 on disk.
• Chinese text could still become mojibake specifically in the exec -> system event -> chat/UI feedback path.

So the issue seems to be in the output transport/rendering pipeline, not necessarily the underlying file bytes.

Repro direction

A likely repro is:

1. Run OpenClaw on Windows 11.
2. Use exec to search or print content from files under docs/zh-CN/... or any path/content containing Chinese.
3. Let the result surface through the system event wrapper (Exec finished / Exec completed / Exec failed).
4. Observe mojibake in the chat/system message, even when source files are valid UTF-8.

Expected

Chinese output should remain readable UTF-8 all the way through the system event / chat rendering path.

Actual

The command may succeed, but the system message that reports the result contains garbled Chinese.

Related context

• [Bug]: Chinese path encoding issue on Windows #5113 reports Chinese path encoding issues on Windows when using exec.
• This new report is about the system-message feedback path also mangling Chinese output on Windows.

Notes

In this environment, terminal encoding was already partially remediated (PowerShell output chain adjusted to UTF-8), but mojibake still appeared in OpenClaw system messages. That suggests the remaining problem is inside OpenClaw's command-result wrapping / transport / rendering path rather than only the terminal.