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:
- Run OpenClaw on Windows 11.
- Use
exec to search or print content from files under docs/zh-CN/... or any path/content containing Chinese.
- Let the result surface through the system event wrapper (
Exec finished / Exec completed / Exec failed).
- 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
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.
Summary
On Windows 11,
execcommand 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
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:
exec -> system event -> chat/UIfeedback 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:
execto search or print content from files underdocs/zh-CN/...or any path/content containing Chinese.Exec finished/Exec completed/Exec failed).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
exec.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.