Codex App: text-log attachment can trigger “Request blocked” and poison subsequent turns

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

• #31820
• #32028

Powered by Codex Action

Additional sanitized reproduction:

• The failure also occurs without attaching a new file to the failing turn.
• A task was continued into a worktree from another Codex App task.
• Earlier in the task, automatic compaction reduced an oversized context from more than 131,072 tokens to approximately 37,000 tokens, after which multiple turns succeeded.
• A later successful diagnostic turn reported 52,695 prompt tokens, 62 output tokens, and finish_reason=stop.
• The next user message contained only a short “continue” instruction.
• That turn immediately failed with the same generic Request blocked. banner and no assistant response.

This suggests that a text-log attachment is one way to trigger the issue, but the persistent failure is more generally tied to inherited/compacted thread state. It may share a root cause with #32028, while this issue additionally covers the thread becoming unusable for subsequent small prompts.

No screenshot, session identifier, raw log, personal information, or local path is included in this comment.

Impact update:

For sustained Codex App workflows, gpt-5.6-sol is currently effectively unusable for me because of this bug.

Short prompts in new threads may work, but long-running tasks repeatedly reach the broken state where:

• a small follow-up such as “continue” returns Request blocked.;
• the affected thread cannot be recovered by retrying, restarting the app, or sending a new attachment-free prompt;
• work must be moved to another thread, losing the accumulated conversational context;
• the replacement thread can eventually enter the same blocked state again.

This has reproduced across multiple tasks using gpt-5.6-sol, including a task that had already compacted successfully and remained well below the reported context-window limit. As a result, the model cannot currently be relied upon for long-running coding tasks in the app.

This is a regression compared with gpt-5.5. In the same Codex App environment, account, and workflow, switching to gpt-5.5 works normally: tasks and follow-up prompts continue without the persistent Request blocked. failure. The same workflow becomes unusable with gpt-5.6-sol.

The working gpt-5.5 control makes an account-wide authentication, usage-limit, or general connectivity problem less likely and points to a regression in the gpt-5.6-sol request/context path.

Same here, my workaround for this issue is switching back to GPT-5.5 and do the compact and then switch back to 5.6 for continuing the original works

Same, and I found @ezoushen's workaround works, but I agree, it makes things unreliable at best. I've had it happen after it was, presumably, thinking for 20 minutes and then in the middle of that, "Request blocked." Sure, I can compact it at that point and reset it to the tune of either waiting another 20 minutes or noticeably worse performance since it doesn't seem like the context from it's 20 minutes of work without output translated to anything in context.

Yep, same here. I tried to continue working this morning and caught this bug in one chat. Everything was fine in the evening. I got up in the morning and it's not OK anymore. I didn't do anything unusual. No big documents. I hope guys from OpenAI is aware of this and fix it soon.

So I can now successfully recreate this issue on command from a new chat with the same prompt. Again, brand new chat, single prompt, all ending in failure.

<img width="963" height="174" alt="Image" src="https://github.com/user-attachments/assets/6d11d626-aba4-4043-9e04-eac9859dc345" />

<img width="1002" height="836" alt="Image" src="https://github.com/user-attachments/assets/0a5a6586-6ab2-4935-81a0-3d6b23718bb1" />

<img width="1009" height="802" alt="Image" src="https://github.com/user-attachments/assets/a58ade26-b5fc-4420-9666-e129afb58cef" />

<img width="1028" height="813" alt="Image" src="https://github.com/user-attachments/assets/0afdb2c4-4307-4048-a0b1-397eee5b24a7" />

and my last prompt on why it happens has been... filtered for profanity "Request blocked keeps happening literally every time I ask this question. I have zero idea why. 1 minute, 2 minute, 10 minutes, in the middle, blocked, why?" but here's the response:

<img width="2323" height="953" alt="Image" src="https://github.com/user-attachments/assets/f0caf9e7-87c7-46e0-b749-588c8c2ca1d0" />

And that's also a fresh prompt. The conclusion at the end seems to be potentially telling?

Cross-referencing a related finding that may help isolate the trigger.

In can1357/oh-my-pi#5184, we performed marker minimization against Copilot gpt-5.6-* and found that the specific text string <|channel|>analysis in the input payload is sufficient to trigger:

{"error":{"message":"Request blocked.","code":"invalid_request_body"}}

Model matrix (same payload, one-shot each):

| Model | Result |
|-------|--------|
| gpt-5-mini, gpt-5.3-codex, gpt-5.4, gpt-5.4-mini, gpt-5.5 | 200 OK |
| gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra | 400 Request blocked |

Not blocked: <|channel|> alone, <|channel|>final, <|channel|>commentary, <|channel|>reasoning, <|channel|>thinking.

This suggests the gpt-5.6-* backend has an input-side safety classifier that rejects requests containing specific Harmony/ChatML control-token combinations — not just output-side moderation.

Your report of compacted thread state triggering Request blocked could share this root cause: if the compacted/serialized context contains Harmony analysis-channel markers, those markers would be present in the input payload. It may be worth testing whether your failing threads contain <|channel|>analysis or similar control-token text.

Additional note: @myleswortham reported being able to recreate this from a new chat with a single prompt (3/3), which suggests the trigger may not require long compacted history — certain prompt content alone may suffice. If you can share the reproducing prompt, we could test whether it contains control-token-like text patterns.

Related: #32533, #32028.

same, thread id: 019f5fb6-069e-7b21-bb28-d9db3ca8f5f1

I hit this 12 times over 8 days for GPT 5.6 models. Root cause matches mentioned above

My project stores GPT-OSS transcripts which includes harmony format, so source files contain <|channel|>analysis tokens. If Codex reads one of those files into context on gpt-5.6-sol and gpt-5.6-terra, the request is blocked. The same files work normally on gpt-5.5.