Emoji in generated output should be opt-in, not default (and the instruction to suppress them does not hold)
From: Donny Hardyanto, PT Ihsan Solusi Informatika (ISI)
Date: 2026-07-29
Product: Claude Code (also applies to Claude via web and API)
Category: Output formatting default, and instruction adherence
---
1. Summary
Claude inserts emoji and decorative pictographs into generated documents and chat output by
default. For professional and regulated work this is not a cosmetic preference. It makes the output
unusable as delivered, and it recurs even after being instructed otherwise.
We are a software vendor delivering to a bank. Every document Claude helps produce - operations
manuals, security specifications, audit findings, handover documentation - has to be stripped of
emoji before it can be sent. That work is repeated on every document and in every project.
Request: make emoji opt-in rather than default, and honour a project-level instruction to
suppress them reliably.
2. What happens
Without being asked, generated documents and replies contain:
- Pictographs on headings, for example a star before the word "Summary"
- Coloured circles used to indicate severity, in place of the words Critical, High, Medium, Low
- Tick and cross marks in table cells, in place of Yes and No
- Warning triangles, keys, maps, lightbulbs, pins, rockets
- Decorative Unicode separators and arrows where ASCII would do
In one working session on a single project this produced approximately 370 emoji across eight
documents, including an 800-line operations manual intended for the customer's DevOps team.
3. Why this is a business problem, not a style preference
| Problem | Consequence |
|---|---|
| Reads as informal | A bank's security auditor receiving a document with coloured circles for severity questions whether it was produced seriously. It damages credibility of otherwise sound technical content. |
| Renders inconsistently | Emoji vary or fail across PDF export, printing, older Office versions, terminals and corporate viewers. Enterprise banking clients use exactly those. |
| Inaccessible | Screen readers announce pictographs unhelpfully or skip them. Where a symbol carries the only indication of severity, the information is lost entirely. |
| Defeats plain-text search | Nobody greps for a red circle. Severity encoded as a symbol cannot be found, filtered or reported on. grep -i critical works; a pictograph does not. |
| Fails document control | Regulated environments require documents to be reviewable, diffable and machine-checkable. Emoji make diffs noisy and validation harder. |
| Cost is repeated per document | Stripping must be done, then reviewed, on every document. Automated stripping introduces its own errors - our own strip pass turned a cross mark into the word "No" and produced the sentence "No Do not copy this seed", which then needed manual repair. |
4. Why instructing the model is not a sufficient fix
We have asked repeatedly, across multiple projects, in several ways:
- Direct instruction in conversation - complied with briefly, then reverted in later turns.
- Project instruction files (
CLAUDE.md) - improved but did not eliminate the behaviour. - Persistent memory entries - same result.
The behaviour returns because it appears to be a strong default in the model's formatting habits
rather than something a single instruction reliably overrides. Longer sessions drift back. A user
should not have to police this on every turn of every project. From our side it currently looks
like the instruction is acknowledged and then quietly ignored, which is worse than not supporting
the setting at all - it means every document still has to be inspected.
5. What we are asking for
- A hard setting - a project or account level option such as
"emoji": "never", honoured for
the entire session, in generated files as well as chat output. A setting that degrades after
twenty turns is not a setting.
- Change the default for document generation. When Claude writes a file, particularly
Markdown intended as documentation, the default should be plain professional prose. Emoji should
be added on request, not removed on request.
- Treat "no emoji" as a hard constraint, in the same class as "do not modify this file". Not
a style hint to be weighed against a formatting preference.
- Use words for meaning. Where a symbol carries information - severity, status, pass or fail -
the word carries it better and survives every medium: Critical, High, Medium, Low, Yes, No,
WARNING.
6. Suggested default behaviour
Emphasis in professional documents should come from structure and wording:
| Instead of | Use |
|---|---|
| Tick or cross in a table | Yes / No |
| Coloured circle for severity | Critical / High / Medium / Low |
| Warning triangle | The word WARNING, or a "Caution:" prefix |
| Star on a heading | Nothing. The heading already says Summary |
| Key, map, lightbulb, pin, rocket | Nothing. Delete it |
| Decorative Unicode arrow | ASCII -> |
Bold on the load-bearing phrase, and capitalised words such as WARNING, are sufficient. They
render everywhere, are searchable, and are accessible.
7. Reproduction
- Ask Claude Code to write technical documentation of any length, for example "write an
operations manual for this service".
- Observe pictographs in headings, table cells and callouts, without having asked for them.
- Instruct "no emoji". Continue the session for a further twenty or more turns, generating more
documents.
- Observe emoji reappearing in later output.
Also reproducible with a CLAUDE.md instruction present from the start of the session.
---
Net effect: Claude Code is genuinely valuable to us for this work - the technical content is
strong and it saves real time. This one default is the main friction in using its output as a
deliverable, and it is entirely fixable with a setting that holds.