Model habitually emits non-ASCII punctuation (em dashes, curly quotes) in code and scripts

Summary

Claude (across Sonnet/Opus, in Claude Code and on claude.ai) habitually emits Unicode em dashes (U+2014), en dashes (U+2013), curly quotes (U+2019, U+201C/D), and horizontal ellipsis (U+2026) in code, shell scripts, YAML, and Markdown -- even when the surrounding file is pure ASCII and the project explicitly requires ASCII.

Em dashes are the worst offender: they appear in nearly every prose response and routinely sneak into generated code, comments, and committed files.

Why this matters

• Breaks grep on the literal characters users typed.
• Breaks diff readability when humans edit on terminals.
• Trips up tooling that assumes ASCII (linters, parsers, downstream shells).
• Sneaks into committed files where reviewers then have to clean it up.
• Forces project-level enforcement (custom CI greps for non-ASCII, repo-level conventions docs telling the model not to do it) that should be a default.

Reproducibility

Asking the model mid-session to stop using em dashes works for that session. The habit returns in the next session. It also leaks into tool-call payloads (file contents written via Edit/Write), not just chat prose -- so a project that has scrubbed its files can be re-polluted by the next assistant edit.

A real example from my own repo: we had to add a section to a conventions doc dedicated to enumerating forbidden non-ASCII characters and a pre-flight grep (\grep -Prn '[^\x00-\x7F]' <dir>/\) because the model kept reintroducing them into CloudFormation templates and shell scripts.

Ask

Please weight ASCII punctuation more heavily in default output, especially inside fenced code blocks and files written via tool calls. Em dashes in prose are debatable as a style choice; em dashes inside a shell script or YAML file are a bug.