codex - 💡(How to fix) Fix Recurrent instruction-to-UI leakage in frontier GPT models: development criteria and agent instructions appear verbatim in final user-facing copy [3 comments, 4 participants]

Summary

This is not about a single isolated example. The concrete shell-script case below is only one instance of a broader, recurrent failure mode across recent GPT frontier models, largely independent of reasoning effort.

The recurring issue is that the model fails to reliably distinguish between:

• instructions to the agent/model about how to implement something
• design/development criteria
• literal end-user copy that should appear in the final product

In practice, this causes process instructions, implementation notes, or development criteria to leak into the generated artifact as if they were user-facing text.

This is especially damaging when building user interfaces. It is routine to find strings that belong to the development process directly rendered into final HTML views, often inside h* headings or p elements.

Why this matters

This is not just a cosmetic copy bug.

It is a prompt-boundary failure that degrades product quality in a systematic way:

• implementation instructions are mistaken for UX copy
• developer-facing constraints leak into end-user surfaces
• generated UI feels prompt-shaped rather than intentionally designed
• cleanup cost is high because these errors are semantically wrong, not just stylistically weak

The issue is particularly harmful in UI work because once these strings land in headings, labels, helper text, cards, or paragraphs, they distort the product itself rather than merely the implementation.

Recurrent Pattern

Across recent GPT models, including the newest frontier variants, it is common to see behavior like:

• "criteria" text showing up as visible labels
• implementation notes becoming explanatory paragraphs in the final page
• developer-oriented caveats rendered into headings or content blocks
• instructions about permission handling, validation, fallback behavior, or structure turned into literal UI copy

This happens even when the user's intent is clearly about implementation behavior, not about the exact wording to render.

Concrete Example

In one recent Codex interaction, the user asked for a CLI script that would toggle FortiClient auto-reconnection with on and off.

The user also said, in effect: if the script needs sudo, make that clear; if not, handle it appropriately.

Codex generated a script that printed:

No hace falta sudo.

in normal success-path output for commands like status, on, and off.

That string was not appropriate end-user copy for the artifact. It was a mistaken literalization of an instruction about behavior and permissions handling.

This specific case was corrected manually, but the important point is that the same class of failure repeatedly appears in UI generation:

• a requirement about implementation is transformed into visible copy
• a design or development criterion becomes rendered content
• model instructions bleed into final user-facing output

UI-Specific Examples of the Same Failure Class

The most damaging versions happen in generated HTML/UI work, where the model places development-time criteria directly into visible elements such as:

• h1, h2, h3
• p
• helper text
• section intros
• empty-state copy
• cards and labels

Examples of the kind of leakage seen in practice:

• headings that read like implementation goals
• paragraphs that explain what the page "should do" rather than what the user needs
• copy that contains development constraints, fallback notes, validation notes, or design-system instructions
• visible text that sounds like a prompt annotation instead of product copy

Expected Behavior

The model should robustly distinguish among at least these categories:

• implementation constraint
• internal reasoning or execution instruction
• product behavior requirement
• literal UX/UI copy
• operator/developer note

A requirement should not become visible copy unless there is strong evidence that the user intended it as actual displayed text.

For UI generation specifically, the model should be conservative about placing explanatory text into visible h* and p nodes unless that copy is clearly product-facing.

Actual Behavior

Recent GPT frontier models recurrently collapse these categories.

As a result:

• agent instructions leak into generated artifacts
• development criteria appear in final copy
• UI strings contain process-language rather than product-language
• the artifact reflects the prompt structure instead of the user intent

Suggested Direction

This likely needs a stronger generation-time boundary check before emitting user-facing text.

Possible mitigations:

• classify instructions before generation into implementation constraint vs visible copy
• require stronger evidence before converting requirements into rendered strings
• add a dedicated "user-facing copy eligibility" check for generated UI text
• apply extra scrutiny to visible HTML nodes such as h*, p, labels, buttons, and helper text
• bias toward minimal visible copy unless the user explicitly requests wording

Scope

Again, this report is not about one shell-script message.

That example is just an easy reproduction of a broader recurrent issue:

• affects Codex/codegen workflows
• affects latest/frontier GPT models as well
• appears across effort levels
• is especially destructive in UI implementation because leakage lands directly in rendered user experiences

Reproduction Heuristic

This can often be reproduced by asking the model to build a UI or CLI artifact while also giving it a mix of:

• implementation constraints
• UX intent
• operational caveats
• conditional behavior notes

The model too often promotes some of those instructions into final copy.

Requested Outcome

Please treat this as a model-quality issue around instruction-boundary handling, not as a one-off wording bug.

The key problem is recurrent instruction leakage into final user-facing artifacts, particularly generated interfaces.