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

[66Ton99]

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

26.707.31428

What subscription do you have?

ChatGPT Team

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

In Codex App, attaching a plain-text application log to an established thread can cause the turn to fail after approximately 3–5 seconds with only:

Request blocked.

The failure is persistent within that thread. Sending a subsequent short message without any attachment also fails with the same generic error because the rejected attachment turn remains in the conversation history.

The affected turns complete without an assistant response. Local thread events show a completed task with no final assistant message. The desktop logs do not show an authentication, rate-limit, or HTTP 401/403/429 failure.

This reproduced with multiple different plain-text logs. The logs contained ordinary service diagnostics, model-loading messages, token counts, and request metadata. They did not contain credentials.

A control request in a new, short thread succeeds with the same account and model.

What steps can reproduce the bug?

1. Open Codex App and use an established local-project thread with substantial completed history.
2. Confirm that a normal turn still succeeds.
3. Attach a plain-text service log. Reproduced attachment sizes ranged from approximately 42 KB / 425 lines to 115 KB / 1,094 lines.
4. Ask Codex to inspect or summarize the log.
5. Observe that the turn ends after approximately 3–5 seconds with Request blocked. and no assistant message.
6. Send a short follow-up without an attachment.
7. Observe that the follow-up is also blocked because the rejected attachment turn remains in the thread history.
8. Create a new thread in the same project and send a short prompt without carrying over the attachment. Observe that it succeeds.

Relevant diagnostics:

• Model: gpt-5.6-sol, medium reasoning.
• Last successful turn before the attachment used 160,985 input tokens with a reported 353,400-token context window.
• Account usage was below 10%; no rate-limit-reached state was reported.
• Directly resuming the affected thread through the bundled CLI reproduces ERROR: Request blocked., so this is not only a stale renderer banner.
• Session identifiers are intentionally omitted for privacy, but can be supplied privately if maintainers provide a secure channel.

What is the expected behavior?

Codex App should do one of the following:

1. Accept the attachment when the combined request fits the supported context and request limits.
2. Proactively compact, truncate, or summarize the attachment/history before sending.
3. Reject the attachment before creating the turn and display a specific actionable error, such as an attachment-size or request-size limit.

A failed attachment turn must not poison the thread. A subsequent message without the attachment should work, or the UI should provide a clear way to remove/rollback the rejected turn.

Additional information

• Reproduced after a full app restart.
• Clearing GUI caches and refreshing authentication did not change the behavior.
• Authentication and ordinary requests remained functional.
• No screenshots or raw logs are attached because they may contain private workspace information.
• No absolute local paths are included in this report.

[github-actions]

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

• Conversation becomes permanently unusable after hitting 50 image limit #31820
• Compaction fails with: Error running remote compact task: Request blocked. #32028

Powered by Codex Action

[66Ton99]

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.

[66Ton99]

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.

[ezoushen]

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

[myleswortham]

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.

[gnmpwr]

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.

[myleswortham]

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.

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:

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

[cuipengfei]

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.