Polish quotes: U+201E opener emitted correctly, U+201D closer emitted as ASCII " (9.6% correct in one session)

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 24, 2026

Report written with AI assistance from inside the affected session; every number below was measured live against the session transcript and against a private monorepo, not estimated.

Summary

When generating Polish prose, Claude emits the opening Polish quotation mark correctly
(U+201E „) and then closes it with ASCII " (U+0022) instead of U+201D ”.

The result looks deliberate rather than broken — the sentence opens with a correct, unusual,
non-ASCII glyph, so a reader assumes the typography was intentional and does not check the closer.

This is the Polish counterpart of #54205 (German, „…“, closed). No Polish variant has been filed.

Environment

Claude Code CLI, model claude-opus-5[1m], macOS 15 (Darwin 25.5.0)
Language of the generated prose: Polish
No proxy, direct Anthropic API

Measured

Session transcript, one working session (2026-08-24). Counting „ … ” (correct) against
„ … " / „ … “ (mismatched) in assistant text blocks:

| producer | mismatched | correct | correct rate |
| --- | ---: | ---: | ---: |
| Claude (this session, chat output) | 47 | 5 | 9.6% |
| OpenAI Codex (994 audit verdicts, same repo, same Polish subject matter) | 21 | 3549 | 99.4% |

The Codex column is the control: it shows the task is not inherently hard and that Polish prose
does not somehow invite the straight quote. Neither producer was ever instructed about quotation
marks — the repository's Polish style rule covers dashes, diacritics and commas, and says nothing
about quotes.

Repository accumulation. The same monorepo (Polish UI and docs, all prose authored by Claude
over ~9 months) currently holds:

4268 mismatched pairs in Markdown prose (excluding fenced and inline code),
21 in shipped user-facing product strings — a cookie policy, two legal disclaimer pages,

an AML onboarding form, an employment form, a transactional email template, a marketing page
and two PDF-generator error messages.

Those 21 were introduced across 8 independent commits spanning 6 months (2026-02-15 to
2026-08-21), so this is a steady generation habit, not one bad import. The most recent one shipped
through a four-axis LLM review gate without any axis noticing.

What is NOT happening here (this is the part that differs from #1599)

#1599 and #54205 describe the Write/Edit tool layer normalizing typographic marks on write,
which would make the defect unfixable from the outside.

That is not what I observe today. In the same session I wrote U+201D through the Edit tool
(4 call sites), through the Write tool (a Python literal '”'), and indirectly through a script,
and every one of them landed byte-correct — verified by re-scanning the files afterwards and by
the resulting test snapshots. #1599's last comment (2026-04-17) reports the write path fixed in
Opus 4.7, which matches.

So on the current build the write path is healthy and the defect sits in generation. That
distinction matters practically: it means a repository-side lint can be enforced (the tools can
emit the right byte), while nothing repository-side can fix prose generated into the conversation.

Reproduction

Ask Claude, in a Polish-language session, to write a few sentences of Polish prose that quote

a phrase — e.g. an explanatory UI empty-state or a paragraph of a privacy policy.

Inspect the bytes of the quotation marks in the reply.

Expected: \xe2\x80\x9e … \xe2\x80\x9d („ … ”)
Actual: \xe2\x80\x9e … \x22 („ … ")

Asking directly for U+201D reportedly does not help (#18422, #1599); I did not re-test that, since
the interesting signal here is the unprompted default rather than compliance under instruction.

Why the asymmetry is worth a separate look

Both #54205 (German) and this report show the low opening glyph surviving while the upper
closing glyph is straight-ified. German closes with U+201C, Polish with U+201D — different
codepoints, same failure. Whatever produces this appears to treat the closer position specifically,
not non-ASCII punctuation generally, which is a narrower and possibly more tractable target than
the broad "Unicode gets normalized" framing of the older issues.

Impact

The affected text is not decorative. In this repository the defect shipped into a cookie policy,
legal disclaimers, a regulatory onboarding form and a customer-facing email. In languages that use
„…” / „…“, mismatched quotes are a visible correctness defect in exactly the documents where
correctness is being asserted.

#54205 — same shape, German („…“), closed
#1599 — tool-layer clobbering of typographic marks, open, cannot be overridden by instructions
#18422 — model reports emitting U+201C/U+201D while emitting ASCII
#23208 — German quotes auto-corrected, closed as stale
#87357 — AskUserQuestion payloads containing „…“ fail validation deterministically (open)

View original on GitHub ↗