[BUG] Bash tool corrupts UTF-8 non-ASCII characters in inline command arguments on Windows (Git Bash)

Resolved 💬 2 comments Opened Mar 6, 2026 by Mationetap Closed Apr 4, 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 the Bash tool executes commands with non-ASCII UTF-8 characters (CJK, accented Latin, Cyrillic, emoji, etc.) in inline arguments on Windows with Git Bash, the characters are corrupted. The same characters are preserved correctly when piped via printf.

Specifically: curl -d '{"text": "Ärger mit Übung"}' → corrupted. But printf '{"text": "Ärger mit Übung"}' | curl -d @- → works fine.

This is NOT a Git Bash issue — running the same curl -d command manually in Git Bash preserves UTF-8 correctly. The corruption happens in how Claude Code's Bash tool passes the command string to the shell.

What Should Happen?

Non-ASCII UTF-8 characters in Bash tool command strings should be preserved correctly, regardless of whether they're in inline arguments or piped.

Error Messages/Logs

No error. The command executes successfully, but non-ASCII characters in the payload are corrupted (mojibake). The receiving server/API gets garbled bytes instead of valid UTF-8.

Steps to Reproduce

  1. Open Claude Code on Windows with Git Bash
  1. Ask Claude to run via Bash tool:

``bash
curl -s -X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d '{"text": "Ärger mit Übung 你好世界"}'
``

  1. Check the response — the "data" field will show corrupted characters instead of Ärger mit Übung 你好世界
  1. Now ask Claude to run:

``bash
printf '{"text": "Ärger mit Übung 你好世界"}' | curl -s -X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d @-
``

  1. Check the response — the "data" field correctly shows Ärger mit Übung 你好世界

Key point: Both commands are executed via the same Bash tool. The difference is inline -d vs printf | pipe. This proves the issue is in how the Bash tool passes inline argument strings, not in the shell or curl itself.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.69 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Root cause hypothesis: The Bash tool constructs the command string in JavaScript/TypeScript (UTF-16 internally) and passes it to the shell spawner. During this handoff, multi-byte UTF-8 sequences in inline arguments may be re-encoded or truncated. The printf workaround works because the shell's own printf builtin generates the UTF-8 bytes directly, bypassing the problematic encoding layer.

Real-world impact: Any agent using Bash to call APIs with non-ASCII payloads (i18n content, CJK text, accented names, emoji) will produce garbled output. This affects curl, httpie, wget, and any command that takes non-ASCII inline arguments.

Workaround:

# Instead of:
curl -d '{"text": "non-ASCII here"}' URL

# Use:
printf '{"text": "non-ASCII here"}' | curl -d @- URL

This works reliably but requires explicit instructions in every agent prompt that uses non-ASCII content in Bash commands.

Related issues: #7332 (Chinese characters), #1716 (UTF-8 corruption), #29699 (Edit tool mojibake)

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗