Codex App streams repetitive garbage tokens into output/composer and enters abnormal turn state after context compaction

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App Version 26.818.41509

What subscription do you have?

ChatGPT Pro x20

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

While using Codex App on Windows with a remote Linux repository over SSH, Codex suddenly began streaming a very large amount of repetitive and nonsensical tokens after previously behaving normally.

Important: the corrupted token stream appeared not only in the assistant output, but also inside the prompt/composer input field. I did not type or paste this content myself.

The failure occurred during a visual UI adjustment task using Codex visual annotations and the Figma integration.

Before the failure, Codex successfully:

• inspected the Figma design;
• inspected repository files;
• identified a CSS spacing issue;
• modified the relevant files;
• ran static checks;
• reported successful validation.

Shortly before the final UI adjustments, Codex displayed:

Contexte compacté automatiquement

("Context automatically compacted")

After my final request, Codex continued working normally for several minutes, including reasoning, file modifications, tool calls and validation.

It eventually executed:

php scripts/media/smoke_publisher_v2_template_context.php
node --check e2e/social-publisher-layout-regression.spec.js
git diff --check -- content/themes/default/css/publisher-v2.css content/themes/default/templates/_head.tpl content/themes/default/templates/_publisher.tpl scripts/media/smoke_publisher_v2_template_context.php e2e/social-publisher-layout-regression.spec.js

git diff --check returned no output and Codex displayed:

Réussite

("Success")

Shortly afterward, the generated text suddenly degenerated into a large repetitive stream containing fragments such as:

LESS
SMART
TH
SS
DOUBLE
SHORT
GOOD

mixed with:

• random numbers;
• repeated punctuation;
• malformed HTML-like fragments;
• isolated technical words;
• fragments from unrelated concepts;
• multiple languages/characters;
• apparently random token sequences.

The output did not recover on its own.

I eventually stopped the task manually.

This did not look like a normal wrong answer or low-quality model response. It appeared to involve a generation, streaming, projection, or turn-lifecycle failure.

---

Key forensic findings

I inspected the persisted rollout JSONL for the affected session.

Affected session

01a0393c-7445-7e81-8e1f-0c70595b85b8

Affected turn

01a03f5e-34e0-7d80-b6fb-ff6f898e21e1

Relevant timeline:

2026-08-26T18:43:49.074Z
Automatic context compaction persisted in the rollout.

2026-08-26T18:44:01.270Z
My final user prompt was persisted normally.

18:44–18:49 UTC
Codex continued producing normal reasoning, messages, tool calls and tool outputs.

2026-08-26T18:49:45.584Z
Last normal persisted activity before the abnormal period.

2026-08-26T19:03:12.323Z
First persisted turn_aborted event.

There is therefore a gap of approximately 13 minutes 26 seconds between the last normal persisted activity and the first turn_aborted.

The garbage text that was visible in Codex Desktop — including inside the composer — does not appear as a persisted assistant or user message in the rollout JSONL.

This may mean that the corrupted content existed only in the live streaming/UI projection state and was never committed as a final response_item.

More importantly, after the first abort, the rollout shows several successive:

task_started
→ turn_aborted

cycles without a new user message between them.

I counted four successive aborted turns.

After I later sent a new normal user message, the same thread returned to normal behavior and successfully completed subsequent turns.

This may be useful for distinguishing:

• a pure model-generation failure;
• a streaming failure;
• an app-server / turn-lifecycle issue;
• a Desktop projection/composer state issue;
• or some interaction between those layers.

The automatic compaction happened shortly before the failure, but I cannot establish that compaction itself caused the corruption.

---

What steps can reproduce the bug?

I have only observed this issue once, so I cannot confirm a reliable reproduction yet.

The exact sequence was:

1. Open Codex App on Windows.
2. Connect to a remote Linux development repository over SSH.
3. Work on a publisher/composer UI using visual annotations and the Figma integration.
4. Send several consecutive small UI adjustment requests.
5. Codex automatically compacts the context.
6. Send another small UI adjustment.
7. Codex continues inspecting/modifying files and running validations.
8. Static checks succeed.
9. Shortly afterward, Codex starts streaming repetitive nonsensical tokens.
10. The corrupted stream also appears inside the prompt/composer field.
11. The output does not recover.
12. Stop the task manually.

The relevant prompts were:

Request 1

Vidéo courte et le logo est trop en bas et a gauche compare avec le design pareil pour le bloc du dessus qui est trop haut et gauche.

Approximate English translation:

In the Short Video view, the logo is too low and too far to the left compared with the design. The same applies to the block above, which is too high and too far left.

Codex inspected Figma and repository files and identified a CSS spacing issue.

Request 2

il me semble aussi qu'il y a un problème sur le bas aussi.

Approximate English translation:

It also seems to me that there is a problem with the bottom spacing.

Request 3

ajoute une marge a droite et gauche de 10 px du bloc pour televerser le fichier pareil pour la progression d'envoi.après le texte ✓ Le brouillon est conservé si vous réduisez le module. ajoute une marge aussi en bas de 20 px.

Approximate English translation:

Add a 10 px left and right margin to the file upload block, and the same for the upload progress area. After the text "✓ The draft is preserved if you minimize the module", also add a 20 px bottom margin.

During this part of the session, Codex displayed:

Contexte compacté automatiquement

("Context automatically compacted")

Final request

l'icone sondage doit faire 35 px par 35 px pareil pour l'icone de humeur du jour

Approximate English translation:

The poll icon should be 35 px by 35 px, and the same for the "mood of the day" icon.

Codex acknowledged the request and continued working normally for several minutes before the degeneration occurred.

---

State of the working tree

The Codex UI showed at the end of the affected task:

5 files modified
+143
-35

Files:

content/themes/default/css/publisher-v2.css
content/themes/default/templates/_head.tpl
content/themes/default/templates/_publisher.tpl
e2e/social-publisher-layout-regression.spec.js
scripts/media/smoke_publisher_v2_template_context.php

After stopping Codex, I inspected the broader working tree separately.

git diff --stat reported:

7 files changed, 460 insertions(+), 79 deletions(-)

The broader working tree also contained existing/related changes, so I am not attributing all seven files to the corrupted turn.

The Codex task had been running for approximately:

24 min 18 s

when I stopped it.

---

What is the expected behavior?

Codex should continue producing coherent progress messages and tool output while executing a coding task.

If the model, context-management system, streaming layer, app-server or Desktop client enters an invalid state, Codex should detect this and either:

• recover automatically;
• retry the generation;
• stop cleanly with an error;
• or ask the user to start a new turn/session.

It should not continue streaming thousands of repetitive nonsensical tokens.

The Desktop app should also ensure that model output cannot unexpectedly populate or corrupt the prompt/composer input field.

If execution becomes invalid, the UI should clearly indicate whether:

• execution has stopped;
• commands are still running;
• file modifications are complete;
• and the current working-tree changes can be trusted.

---

Related issue

This appears related to #40369, but I am not sure it is an exact duplicate.

Some important differences:

• #40369 occurred in Codex CLI on Linux with GPT-5.6 Sol.
• This occurred in Codex App on Windows with GPT-5.6 Ultra.
• This session used a remote repository over SSH.
• Automatic context compaction occurred shortly before the failure.
• The corrupted stream appeared inside the Desktop prompt/composer field.
• The garbage does not appear as a persisted assistant/user message in my rollout JSONL.
• The rollout shows abnormal task_started → turn_aborted cycles after the incident.

The two reports may still share the same underlying model-generation failure, but this report may additionally expose a Desktop streaming/projection or turn-lifecycle problem.

If maintainers confirm that both issues share the same root cause, I am happy for this issue to be closed as a duplicate.

---

Additional information

The issue occurred on August 26, 2026.

Environment:

• Codex App on Windows
• Codex App Version 26.818.41509
• ChatGPT Pro x20
• GPT-5.6 Ultra
• Remote Linux repository over SSH
• Figma integration
• Visual annotations
• Several consecutive UI adjustment turns
• Automatic context compaction during the session

There was no visible error message immediately before the textual degeneration.

I preserved:

• the complete corrupted session output;
• the rollout JSONL;
• the exact prompts;
• the affected Session ID and Turn ID;
• Desktop logs;
• screenshots;
• git diff information.

I can provide sanitized excerpts of the rollout JSONL and Desktop logs if useful.

I do not want to publish the complete raw JSONL or local database publicly because they may contain unrelated prompts, repository data, local paths or other sensitive information.

Complete visible session transcript:

Fichier markdown(20260826-192220).md

Start by comparing the affected rollout JSONL and Desktop logs around 18:49–19:03 UTC, focusing on the first turn_aborted event and the repeated task_started → turn_aborted cycles. Compare the findings with related issue #40369 and the preserved transcript. Done means identifying the failing layer or a reliable reproduction, with invalid execution stopping cleanly and model output unable to populate the composer.