gpt-5.6-sol “Request blocked” permanently poisons a long-running /goal thread

[didicayu]

What version of Codex CLI is running?

The affected rollout was created with codex-cli 0.144.4. The current installation is codex-cli 0.145.0, and the thread remains unusable.

What subscription do you have?

ChatGPT Pro.

Which model were you using?

gpt-5.6-sol with ultra reasoning effort. Changing the effort to xhigh did not recover the thread.

What platform is your computer?

• macOS 26.2
• Apple Silicon / arm64
• VS Code integrated terminal 1.108.2

Codex doctor report

A redacted doctor summary run with normal network access on 0.145.0 reported:

16 ok | 1 idle | 2 notes | 1 warn | 0 fail degraded
auth: configured
state databases: healthy
rollout files and state DB thread inventory: agree
websocket: connected (HTTP 101)
provider endpoints: reachable over HTTP

The only warning was for optional MCP configuration and does not affect normal Codex requests.

What issue are you seeing?

While using a long-running /goal to improve and evaluate a custom GPT-OSS assistant for a legitimate health/fitness application, a turn suddenly ended with only:

Request blocked.

The work involved ordinary LLM engineering: primary-source research on LLM/agent/RAG evaluation, multilingual regression cases, deterministic tool and citation checks, live GPT-OSS evaluations, and scoped prompt/tool/evaluator improvements. Immediately before the failure, Codex was diagnosing GPT-OSS/Harmony tool-calling behavior and searching for relevant official sources.

At the time of the first visible failure, the goal UI reported approximately:

Status: blocked
Time used: 39m
Tokens used: 579K

There was no explanation of which content or action was considered problematic, no request ID, and no recovery guidance.

The first rejection permanently poisoned the existing thread:

• short benign follow-ups such as continue are also blocked;
• asking what happened is blocked;
• changing the subject is blocked;
• manual compaction does not recover it;
• changing reasoning effort from ultra to xhigh does not recover it;
• the goal remains blocked and unfinished;
• a new thread works normally with the same account and installation.

Sanitized local rollout inspection shows that later recovery turns record task_started, then complete about 4–8 seconds later with no assistant message. The local goal database remains healthy but records this goal as blocked. This looks thread-specific, not like an authentication, connectivity, quota, or local-state failure.

The original thread ID and fuller diagnostics can be supplied privately if maintainers provide a secure channel. I am not attaching raw logs because they contain private workspace information.

What steps can reproduce the bug?

The initial trigger is intermittent, but the poisoned-thread state is persistent:

1. Start a long-running /goal using gpt-5.6-sol with ultra effort.
2. Perform normal development and evaluation work involving an open-source LLM, including inspecting model outputs, tool-call serialization, and evaluation reports.
3. Continue through substantial accumulated context and one or more compactions.
4. Observe a turn end with only Request blocked..
5. Send a short benign message such as continue.
6. Observe the same block with no assistant response.
7. Try manual compaction, a harmless change of subject, or a different reasoning effort.
8. Observe that the same thread remains unusable while a new thread works.

What is the expected behavior?

If a request genuinely violates a policy, Codex should:

• explain the applicable category at an actionable level and provide a request/reference ID;
• reject only the offending turn;
• allow the user to edit, remove, or roll back the rejected turn;
• allow later benign messages to continue;
• avoid automatically terminalizing an otherwise valid /goal;
• expose a reliable Resume/Retry recovery path.

Legitimate development and evaluation of open-source LLM services should not be falsely blocked merely because prompts, logs, or source material mention model internals, tool calling, Harmony tokens, or other model names.

Additional information

Related reports found before filing:

• "Request blocked" while working normally in a codex session #34157 — the same generic Request blocked behavior with gpt-5.6-sol during open-source model development, but without this detailed persistent /goal failure.
• Codex App: text-log attachment can trigger “Request blocked” and poison subsequent turns #32177 — a blocked request poisoning subsequent turns, originally associated with text-log attachments and long/compacted context.
• False positive - cybersecurity block #33962 — a false-positive safety block during legitimate development in a /goal.
• Codex Desktop: remote-compaction capacity error terminalizes one persistent goal while other tasks remain healthy #33171 — a goal becoming stuck as blocked after a different trigger (remote-compaction capacity failure).

This report focuses on the combination of a likely false-positive safety block, persistent thread poisoning, and an unrecoverable blocked goal after legitimate GPT-OSS development work.

[github-actions]

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

• Long Codex task becomes permanently "Request blocked" after successful completion #33973
• "Request blocked" while working normally in a codex session #34157
• CLI: Request blocked (not during compaction) #35014

Powered by Codex Action

[scouzi1966]

I get the same many times and it's really annoting. Please fox this OpenAI

[TheLunarD]

i got the same situation in using a remote server, each conversation can only live like 15 minutes and ended with request blocked

[justiniver]

Is there a workaround for this? Can we somehow disable the GPT-OSS/Harmony tool-calling

[Astrotech1989]

I hit the same failure mode on Windows 11 in VS Code with a ChatGPT Pro account while doing legitimate local-model integration work.

Context: the thread was integrating a local GPT-OSS model through an adapter and validating that the real Codex edit loop, reasoning-effort selector, file-change behavior, and documentation updates were working. The preceding Codex turn completed normally and reported 19 files edited (+629 / -108).

Immediately afterward:

1. I sent continue.
2. Codex returned only Request blocked.
3. I sent continue again.
4. The same generic Request blocked. response appeared.

There was no explanation, request/reference ID, or recovery path. The working-tree edits still appeared to be present, so the failure looks thread-specific rather than an edit or repository failure. The blocked thread was captured in a screenshot on 2026-08-02 at approximately 23:15 CDT.

This is another reproduction involving a long-running GPT-OSS/custom-adapter workflow where a benign follow-up becomes permanently blocked. I can provide the screenshot and additional sanitized diagnostics if maintainers specify a secure or preferred channel.