[App] Intermittent false-positive `invalid_prompt` on benign software tasks in fresh gpt-5.6-sol threads
Summary
Codex Desktop intermittently rejects completely benign software-development prompts with:
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
This is happening across multiple brand-new threads and multiple ordinary local repositories. The prompts are routine product/UI/backend development requests, not cybersecurity or other safety-sensitive work.
Environment
- Codex Desktop app on macOS
- Model:
gpt-5.6-sol - ChatGPT subscription auth
- Multiple local Git repositories / workspaces
- Observed on 2026-08-20 / 2026-08-21 (UTC+8)
I do not have the exact Codex Desktop build number handy, but can provide it if needed.
Examples of benign prompts that were blocked
Examples include requests equivalent to:
- "I want the modal to take up 5/6 of the screen width."
- Ordinary travel-admin UI work: adjust a user-tracking table, add an expandable row, reuse an existing nickname/remark field, and add a link to an itinerary-management page.
- Ordinary travel-planning schema/design work involving fields such as
scenario,capacity,pax, andvehicle_num.
None of these requests involve credential access, exploitation, bypassing authentication, scanning, malware, or any other cybersecurity activity.
Important behavior / reproduction pattern
The rejection is intermittent rather than tied to a specific user prompt:
- Open a brand-new Codex Desktop thread in a local repository.
- Ask Codex to read the workspace rules /
AGENTS.mdand inspect the repo. - Codex can often read files, inspect git status/diffs, and even perform ordinary edits successfully for several minutes.
- A subsequent benign prompt may suddenly fail with
invalid_prompt. - Open another fresh thread against the same repository and send essentially the same benign request.
- The request may succeed normally there.
- A plain fresh chat with a simple greeting also succeeds, so the account/model is not globally blocked.
In one observed thread, the rejection appeared after the UI showed that the conversation context had been automatically compacted. However, the problem is not limited to old threads: I also reproduced it in newly created threads.
The strongest observed contrast was that the same repository/model could have one thread rejecting a simple modal-width change while another fresh thread was simultaneously inspecting and implementing the same UI task normally.
Expected behavior
Benign local software-development prompts should not be rejected by the safety classifier. If a safeguard does reject a request, the App should ideally expose a request/feedback ID so false positives can be investigated without repeatedly retrying the prompt.
Additional information
This looks similar to #39687 and the older #7250, but this report is specifically about the current Codex Desktop App, gpt-5.6-sol, multiple fresh threads, and ordinary product/UI/travel software development where the same prompt can fail in one thread and succeed in another.
I have multiple screenshots showing the parallel threads and the benign prompts that triggered the error, and can provide them if maintainers need them.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Same issue in feedback: 01a02a43-20ec-7d52-a7e9-887d87b68fdb
When I ask codex what I did:
Nothing in your request was inappropriate. You’re debugging ordinary NPC navigation and scheduling in your own game; that’s fully legitimate.
If Codex showed a “usage policy” warning, it was almost certainly a false positive from an automated classifier—not something you should avoid phrasing next time. I don’t have visibility into the exact classifier trigger, but likely candidates in the logs are generic words such as “failed,” “blocked,” or “satisfy need” being interpreted without the surrounding game-simulation context. You did nothing wrong, and I’m continuing the debugging work.
Immediately after this reply from codex it triggered another potential violation flag.
Another occurrence on Codex Desktop for macOS using
gpt-5.6-solwith ultra reasoning. Two benign Chinese product-documentation prompts were processed normally at first—the model produced reasoning, commentary, and even spawned a subagent—but the stream later terminated with the genericinvalid_promptusage-policy error. Local records contain onlycodexErrorInfo: otherwith no policy category or moderation details. This appears to be a mid-stream false positive involving the assembled context or safety buffering, rather than the visible user prompt. Observed on 2026-08-23 (UTC+8).Adding another occurrence that appears to be the same failure class.
Environment
26.818.41509What happened
I am developing a local personal software application using normal Python/SQLite/backend/frontend engineering workflows.
The affected task was implementing the next phase of the application. The feature work involved ordinary product functionality:
The user-facing instruction that started one of the affected runs was essentially:
There was no request to access a third-party system, obtain credentials, perform offensive security work, scan anything, or bypass authorization.
Codex successfully began working on the repository. It inspected the codebase, made implementation changes, and ran tests.
Later in the same implementation session it terminated with:
This therefore appears to be a mid-run safety false positive, not simply rejection of the initial visible prompt.
I also tried rewriting the engineering plan
The original implementation plan contained normal defensive engineering requirements involving external-input validation, authorization boundaries, privacy, provider-output validation, and safe network handling.
Thinking that terminology might be causing the classifier to misread the task, I rewrote the entire phase plan to be much more outcome-focused.
For example, detailed defensive test descriptions were replaced with requirements such as:
and:
The implementation requirements themselves were unchanged.
Despite that rewrite, Codex later encountered the same
invalid_promptfailure while continuing ordinary development work.That makes me suspect the failure may involve the assembled conversation/repository context, model-generated intermediate content, or some broader safety-check state, rather than a deterministic bad phrase in the user's prompt.
Particularly concerning: partial implementation state
The failure can occur after Codex has already edited production files and run tests.
That creates a lifecycle problem in addition to the false positive:
This resembles #39539, where a benign implementation was blocked after filesystem writes.
For large autonomous coding tasks, this makes the failure especially disruptive because the user then has to determine manually which parts of the planned change were completed and whether the worktree is internally consistent.
Same repository/task works with another coding agent
As a practical comparison, I moved the same repository and remaining implementation work to Claude.
It was able to continue the same software-development task normally.
That does not identify the precise root cause, but it suggests the repository itself, the implementation requirements, and the local development workflow are not inherently malformed or impossible to process.
Additional observation
What makes this look particularly similar to this issue is that changing the visible launcher prompt does not reliably solve it.
The initial instruction can be extremely ordinary, while the policy rejection happens only later after Codex has read repository files, accumulated implementation context, generated its own planning text, and performed tool calls.
That seems consistent with the reports in this thread where benign prompts initially process normally and the stream subsequently terminates with
invalid_prompt.Expected behavior
Normal local application development should complete without being classified as prohibited cybersecurity work.
If an additional safety check does terminate a long-running Codex task, it would help enormously if Codex exposed:
Ideally, safety termination after filesystem mutation should also have a recovery/checkpoint mechanism so an interrupted agent cannot leave a repository in an ambiguous partial state.