Invalid prompt bug

English translation:

What version of Codex CLI is running?

codex-cli 0.149.0

What subscription do you have?

max20

Which model were you using?

gpt-5.6-sol high fast

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

Codex doctor report

Invalid prompt: your prompt was flagged as potentially violating our usage policy. Please try again with a different prompt: https://platform.openai.com/docs/guides/reasoning#advice-on-prompting

What issue are you seeing?

• Complete error text and time of occurrence
• codex --version
• Working directory: /Users/mark/mvmdex/.worktrees/swap-market-alert-20260823
• Clearly state that this was a brand-new thread, involved local workflow editing, and prohibited remote operations
• YAML validation succeeded; the error occurred before the patch was applied
• Handoff file path: /Users/mark/mvmdex/.agents/handoffs/2026-08-23-market-availability-workflow-resume.md
• Do not include any keys, environment variable values, or complete deployment logs

What steps can reproduce the bug?

Uploaded thread: 01a031e2-0a5f-7931-8079-5663233231d7

What is the expected behavior?

_No response_

Additional information

_No response_

<!-- codex-issue-translator -->

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

• #39745
• #39742

Powered by Codex Action

I investigated #40327 and implemented a minimal client-side fix that recognizes the legacy usage-policy invalid_prompt message through the existing safety-block handling.

I also added regression coverage for the reported message and verified the relevant Codex TUI tests pass.

The change intentionally does not bypass or modify server-side safety enforcement.

Would a maintainer be willing to invite me to submit this as a PR?

I can reproduce this on a newer CLI and in multiple context-isolation modes.

Environment:

• Codex CLI 0.149.1
• gpt-5.6-sol, high reasoning
• Linux 6.12.44 x86_64
• Occurrences on 2026-08-25 UTC
• Ordinary local TypeScript model refactoring in an isolated Git worktree; no cybersecurity, credential, deployment, or third-party-target activity

Observed sequence:

1. A fresh built-in sub-agent with no inherited turns read the repository instructions and applicable design context, then terminated with:

> Invalid prompt: your prompt was flagged as potentially violating our usage policy.

1. A fresh standalone Codex CLI session in tmux reproduced the same failure. That attempt had run an unconstrained TypeScript check whose roughly 700 diagnostics entered the conversation context, so large tool output was initially suspected.

1. A second fresh standalone tmux session was launched with an explicitly bounded handoff. It was instructed to redirect broad diagnostics to /tmp and inspect only small targeted slices. It successfully ran one focused Vitest file (5 tests passed and 1 intentional TDD tracer failed), then performed only read-only repository/diff mapping. It was rejected with the same invalid_prompt error before making any new file edit and before running the broad TypeScript check.

The third occurrence weakens the hypothesis that the rejection requires a large diagnostic stream. Fresh context, no inherited conversation, a sanitized benign handoff, isolated worktree execution, and bounded tool output were insufficient to prevent it.

Expected behavior: the benign local implementation session should continue. If a policy check terminates it, Codex should expose a stable request/feedback ID and a machine-readable reason so false positives can be reported without repeatedly attempting reproduction.

I can provide sanitized session identifiers or additional bounded diagnostics if maintainers say which fields are useful. No private source, local handoff contents, or credentials are included here.

Thanks for the detailed reproduction. I was able to trace the client-side handling of the failure.

I found two separate issues:

1. The reported legacy invalid_prompt wording is not recognized by the existing safety-block presentation logic.
2. More importantly, Codex already has diagnostic identifiers available (response.failed.id and the upstream x-request-id), but they are not surfaced to the user when the request is blocked.

I’m working on a small client-side change to preserve and surface these identifiers in the existing policy-block notice, while keeping the request blocked and leaving the server-side safety behavior unchanged.

I’ll also add regression coverage for the identifier handling and the legacy message classification. This should allow future false-positive reports to include a stable request/response identifier without repeatedly reproducing the request.

I’ll share the patch once I’ve completed and verified it.