Unexpected anomalous Cyrillic characters appended to Codex CLI output

[Kenchan1111]

What issue are you seeing?

Bug summary

While using Codex CLI, I observed an unexpected fragment appended to a response:
<Let's answer in French. Minimal but substantive. +#+#+#+#+#+қты.>

The trailing characters appear abnormal in this context and seem to include Cyrillic characters.

I am opening this issue to determine whether this fragment was:

1. present in the raw response returned by the service, or
2. introduced later by the local client, terminal rendering layer, encoding, or Codex CLI itself.

Context

My system is configured in French:

• Locale: fr_FR.UTF-8
• Shell: bash
• Time zone: Europe/Brussels (CEST, [UTC+02:00)]

In this environment, unexpected Cyrillic characters at the end of a Codex CLI response are out of place and deserve verification.

Security relevance

I am not claiming that this element alone proves a compromise.

However, I am currently investigating suspicious local network behavior and possible DNS redirection anomalies in my environment. Because of that context, I want to rule out several possibilities, including:

• anomalous model output returned by the service,
• client-side rendering or encoding corruption in Codex CLI,
• local workstation/environment-side corruption,
• or, less likely but still worth excluding, a transport-path issue if the raw server-side response did not contain the fragment.

I am reporting this conservatively as an anomalous output issue with possible security relevance until the origin of the fragment is clarified.

Reproduction

At this stage, reproduction is not yet confirmed.

Reproducibility

• Reproducible every time
• Intermittent
• Observed at least once
• Exact trigger currently unknown

Steps to reproduce

At the moment I do not have a minimal deterministic reproduction.
I will add one if I can isolate the conditions.

Environment

• Codex CLI version: 0.125.0
• OS: Fedora release 43 (Forty Three)
• Kernel: Linux 6.19.9-200.fc43.x86_64
• Architecture: x86_64
• Shell: bash
• Locale: fr_FR.UTF-8
• Time zone: Europe/Brussels (CEST, UTC+02:00)

Raw observed string

Let's answer in French. Minimal but substantive. +#+#+#+#+#+қты.

Questions for maintainers

1. Has this type of anomalous trailing fragment already been reported in Codex CLI?
2. Is there any known issue involving terminal rendering, Unicode handling, encoding, or post-processing of model output?
3. Can you confirm whether the raw server-side response already contained the anomalous fragment?
4. If the raw response did not contain it, could this indicate a client-side corruption issue in Codex CLI or another local rendering/encoding problem?
5. Is there a recommended way to capture or inspect the raw response before terminal rendering for verification?
6. If request/completion identifiers exist locally, where should I look to retrieve them?

Notes

I am intentionally reporting this conservatively as an anomalous output / rendering / encoding issue until stronger evidence exists one way or the other.

What steps can reproduce the bug?

I do not yet have a deterministic minimal reproduction.

Observed scenario:

1. Use Codex CLI in a Fedora 43 terminal environment.
2. System locale is set to fr_FR.UTF-8.
3. Interact normally with Codex CLI and request a response in French.
4. In at least one observed case, the response ended with an anomalous fragment:

"Let's answer in French. Minimal but substantive. +#+#+#+#+#+қты."

At this stage, I cannot confirm the exact trigger conditions. I am reporting the issue because I need to determine whether the anomalous trailing characters were already present in the raw server-side response
or introduced later by the local client / terminal / rendering layer.

What is the expected behavior?

Codex CLI should display only the intended response text, with no unexplained trailing characters or out-of-context Unicode fragments.

In particular, on a system configured with fr_FR.UTF-8, a normal response should not unexpectedly end with unrelated Cyrillic-looking characters unless they are explicitly part of the intended model output.

Additional information

Environment:

• Codex CLI: 0.125.0
• OS: Fedora 43
• Kernel: Linux 6.19.9-200.fc43.x86_64
• Architecture: x86_64
• Shell: bash
• Locale: fr_FR.UTF-8
• Time zone: Europe/Brussels (CEST, UTC+02:00)

Observed string:
"Let's answer in French. Minimal but substantive. +#+#+#+#+#+қты."

Report preparation timestamp:

• Local: 2026-04-28T19:32:29+02:00
• UTC: 2026-04-28T17:32:29Z

Important note:
I am not claiming that this alone proves a compromise. However, I am currently investigating suspicious local network behavior and possible DNS redirection anomalies in my environment, so I want to rule out:

• anomalous model output,
• client-side rendering/encoding corruption,
• Codex CLI post-processing issues,
• or another local display / transport-path issue.

I can provide screenshots and additional context if needed.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Unexpected adult-site string appended to output #18986

Powered by Codex Action

[etraut-openai]

Thanks for the bug report. This appears to be model behavior, not something that can be addressed in the Codex harness. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the /feedback command. That will provide us with additional details including logs and conversation text.

[Kenchan1111]

Thank you for the response.

I need one precise clarification, because this is the key technical point for me.

When you say:

"This appears to be model behavior"

do you mean that the anomalous fragment was actually present in the raw model/server-side response?

More specifically, can you confirm whether the exact fragment below was emitted by the model itself:

Let's answer in French. Minimal but substantive. +#+#+#+#+#+қты.

My question is not whether this is generally considered a Codex harness bug or a model issue in your internal triage process.

My question is specifically:

- was this fragment present in the raw response returned by the service, or
- is “model behavior” only a triage assessment without confirmation of the exact emitted text?

If you cannot confirm the raw emitted text, please state that explicitly.

This distinction matters, because without it I still cannot determine whether I am looking at:

- confirmed raw model output,
- local rendering or encoding corruption,
- a client-side issue in Codex CLI,
- or a local compromise of my computer or of the Codex installation.

I have already submitted feedback separately as well, since I understand the GitHub issue tracker and the feedback pipeline may be handled by different teams.