Repository navigation
GPT-6 Astra rejects hi with invalid_prompt: isolated CLI and minimal backend reproduction across Linux/macOS #43237
Description
What version of Codex CLI is running?
0.153.4 (Linux x86_64 standalone musl build). The npm stable version was also 0.153.4 when checked during diagnosis on September 6, 2026.
What subscription do you have?
ChatGPT subscription sign-in, not an API-key/custom-provider setup. Exact subscription tier is not included in this report.
Which model were you using?
Failing: gpt-6-astra, reasoning effort high.
Working control: gpt-5.6-sol, also high.
What platform is your computer?
- Primary reproduction: remote Linux x86_64 host, accessed over SSH.
- Independent transport comparison: macOS, using the same account's credentials for a minimal backend request. This was not a macOS Codex CLI comparison.
What terminal emulator and version are you using (if applicable)?
Shell over SSH for the Linux CLI reproduction. The additional minimal request tests do not depend on an interactive terminal UI.
Codex doctor report
Not collected for this report. The evidence below includes an isolated CLI test and a minimal request outside the CLI.
What issue are you seeing?
GPT-6 Astra fails even when the entire user prompt is hi:
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
GPT-5.6 Sol responds normally using the same account, machine, prompt and reasoning effort.
Related reports already describe similar symptoms: #43058 and #43163. This report adds a minimal backend reproduction with no tools, skills, project content or conversation history, plus a Linux/macOS transport comparison and a response ID for investigation.
What steps can reproduce the bug?
1. Isolated CLI comparison
I tested with separate temporary Codex homes containing only the existing account's authentication material, and an empty working directory. User configuration was ignored and apps, plugins and multi-agent features were disabled. No original configuration or conversation history was changed.
The command shape below uses placeholders for those temporary directories:
CODEX_HOME="$CLEAN_CODEX_HOME" codex exec \
--ignore-user-config \
--skip-git-repo-check \
--disable multi_agent \
--disable apps \
--disable plugins \
--sandbox read-only \
-C "$EMPTY_WORKDIR" \
-m gpt-6-astra \
-c 'model_reasoning_effort="high"' \
--json hiResult: invalid_prompt, exit code 1.
The same test with a separate clean control home and -m gpt-5.6-sol succeeded and returned a normal greeting.
2. Minimal backend comparison outside the CLI
To distinguish CLI/context issues from backend behavior, I also sent a minimal streaming request to the official ChatGPT Codex backend used by this login:
POST https://chatgpt.com/backend-api/codex/responses
Payload:
{
"model": "gpt-6-astra",
"instructions": "You are a helpful assistant.",
"input": [
{
"role": "user",
"content": [
{
"type": "input_text",
"text": "hi"
}
]
}
],
"reasoning": {
"effort": "high"
},
"store": false,
"stream": true
}There were no tools, skill descriptions, project instructions, previous-response references or prior messages. Authentication headers are intentionally omitted. No third-party model endpoint was used.
Results:
| Test | GPT-6 Astra | GPT-5.6 Sol |
|---|---|---|
| Isolated Linux Codex CLI | invalid_prompt |
Normal greeting |
| Minimal request from Linux | HTTP 200, then SSE error / response.failed with invalid_prompt |
Normal completed response |
| Minimal request from macOS using the same account | HTTP 200, then SSE invalid_prompt |
Normal completed response |
The macOS comparison used HTTP/1.1 through the machine's existing local proxy. Preliminary transport failures were excluded from the model comparison; both final macOS model requests reached the backend. TLS verification was not disabled.
What is the expected behavior?
A fresh request consisting only of a neutral instruction and hi should produce a normal greeting. If there is an account/model availability problem, the error should identify that problem rather than reporting that this harmless prompt violates usage policy.
Additional information
Observed on September 6, 2026.
A failed GPT-6 response ID from the minimal macOS request:
resp_04bdc6162de489b7016a9d7eb64f3487d0ac8f4fbc02700168
A successful GPT-5.6 control response ID from the same comparison:
resp_055fbf2af5013180016a9d7eb9ffa087d086d5812364243ee8
These results make a Linux-only installation, SSH connectivity, user skill, or conversation-history explanation less likely. They do not establish the exact root cause, prove the problem is account-specific, or imply all Astra accounts are affected. Could maintainers investigate the failed response and whether model-specific request handling or account state explains the discrepancy?
Temporary workaround: use GPT-5.6 Sol. This does not restore Astra.
No auth.json contents, access/refresh tokens, account identifiers, private file paths, source code or full session transcripts are included.
Activity
github-actions commentedon Sep 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
17Reset commentedon Sep 7, 2026
+1
233stone commentedon Sep 7, 2026
I can reproduce this on macOS in Codex Desktop.
invalid_promptfailures across multiple threads and unrelated projectsgpt-6-astrahigh,xhigh, andmaxreasoning effortgpt-5.6-solturns completed successfullyA direct comparison occurred with the same prompt:
max) failed withinvalid_promptat 10:06:15 CSThigh) succeeded with the same prompt at 10:07:07 CSTUnlike some reports, the behavior is intermittent rather than affecting every Astra request. Harmless prompts across different projects can fail, while switching to GPT-5.6 Sol resolves the problem.
Representative failed turn ID:
01a0799d-a0de-7c21-984d-1bb3b8b0fa94Successful GPT-5.6 control turn ID:
01a0799d-f687-79f2-9e12-2897c52c710dclchen3667 commentedon Sep 8, 2026
I am seeing the same account-scoped regression. GPT-6 Astra worked normally earlier on 2026-09-08, then began rejecting every prompt.
Minimal reproduction on macOS with the bundled Codex CLI 0.153.4:
The failure reproduced around 2026-09-08 14:47 Asia/Shanghai. Internal /feedback diagnostics were uploaded under session/thread ID:
01a07fcf-a4b1-7112-8e2e-6ebb1213fe13
This looks consistent with an Astra account-routing or safety-check regression rather than the prompt content.
BCAutumn commentedon Sep 9, 2026
same issue, gpt-6 rejects every request, both codex and website
feedback id: 01a0840e-0e42-7bc2-99a0-717cc7776286
Maybank01 commentedon Sep 9, 2026
+1
tcl326 commentedon Sep 10, 2026
+1
FansenXi commentedon Sep 11, 2026
Reproduced consistently in Codex Desktop on Linux x86_64 with bundled runtime 0.153.4 and ChatGPT account authentication.
Observed in four separate fresh Desktop threads on September 9, 10, and 11, 2026. In each case, the complete user-entered text was simply
hi, andgpt-6-astrareturned:Invalid prompt: your prompt was flagged as potentially violating our usage policy.A same-environment control using
gpt-5.6-solworks normally. Local configuration, authentication, app-server, and installation checks all pass. This appears to be an Astra-specific false positive or account/model-routing issue rather than prompt content. Representative failed Desktop thread ID:01a08f37-531b-7410-9df9-272e9a8d1333.freanocank commentedon Sep 12, 2026
Additional macOS Codex App reproduction from the same ChatGPT account:
Invalid prompt: your prompt was flagged as potentially violating our usage policy.codex_error_info: "other"and has no assistant/output item, while the Sol control produces a normal assistant message.This suggests the Astra turn is failing before model output (possibly session/turn initialization or model-routing/gateway validation), with the policy text acting as a generic fallback. It does not look like a genuine prompt-content violation or a capacity error. Related App report: #44700.
freanocank commentedon Sep 12, 2026
Follow-up diagnostic (macOS, 2026-09-12; current Codex App 26.908.40834, bundled CLI 0.154.0-alpha.6.2):
I re-ran the comparison with a clean temporary CODEX_HOME containing only the existing ChatGPT authentication material, an empty working directory,
--ignore-user-config, and no project/plugin context.gpt-6-astrawith a minimal harmlesshirequest fails at low and max reasoning, with both the default and priority service tiers.gpt-5.6-solwith the identical clean invocation succeeds.response.in_progress, then a servererror; there is no assistant output.https://chatgpt.com/backend-api/codex/responses: Astra returned HTTP 200 followed by an SSEerror(code: invalid_prompt) andresponse.failed(request ID1826a250-4dcf-4dad-b76f-65ad18d7141c), while Sol returnedresponse.completed(request ID982aad38-4636-44a3-96a5-dc201ea69636).gpt-6-astrafor the Pro plan and advertises reasoning levels throughultra; current usage limits were not reached.This rules out local config, project context, plugins, a missing entitlement, and capacity as the primary cause. The policy message appears to be a misleading model/account-specific backend failure. Related App report: #44700.
shijianbert-prog commentedon Sep 13, 2026
Additional account-scoped macOS reproduction (still failing on 2026-09-13):
Reply exactly: OK.OK.Internal
/feedbackdiagnostics were uploaded successfully with 7 attachments under session/thread ID:01a08de8-48a7-7540-a018-f2c8ca654153.This makes prompt content, local configuration, quota, and reasoning effort unlikely. It is consistent with an Astra account/model-routing or safety-check false positive. Please use the uploaded session to investigate. No authentication data, private paths, source code, or chat transcript is included here.
x-w-d commentedon Sep 14, 2026
Additional macOS reproduction, still present on 2026-09-14:
26.908.40834(com.openai.codex)codex-cli 0.154.0-alpha.6.2你好(a neutral Chinese greeting)I first reproduced this in a fresh Desktop task, then reproduced it twice with the bundled CLI in an independent read-only invocation:
Results:
gpt-6-astrahighinvalid_promptusage-policy messagegpt-6-astralowinvalid_promptmessagegpt-5.6-solhighRepresentative CLI session IDs:
01a09ecf-6f78-74d2-bc9d-6903af0c3e3801a09ecf-cec5-7401-b78b-f4fd55d6839e01a09ed0-108a-7970-85a3-959ca8f0f8f2codex doctorreports a consistent installation and healthy config/auth/state. The WebSocket connected with HTTP 101 and active provider endpoints were reachable. App logs show the task and app-server initializing normally, with no local exception corresponding to the policy message.Switching the default model to
gpt-5.6-solimmediately restores normal operation. This adds evidence that the Astra-specific backend false positive remains active on the current 26.908 desktop release and affects harmless non-English input at both low and high reasoning effort.No authentication data, private paths, source code, or full logs are included.
feiweiliang commentedon Sep 14, 2026
Same symptom here, but with one difference that may narrow the search space: for me it is
not model-specific. I hit it on
gpt-5.6-solas well asgpt-6-astra.Environment:
0.154.0-alpha.6.2and was rejected at 16:08 local on 2026-09-14 (UTC+8)
The variable that correlates with the outcome on my machine is the client identifier the
request carries, not the prompt content. The request body is byte-identical between a
passing and a failing run (checked with
codex debug prompt-input): same 5 input items,same 32,360 bytes. Only the
originatorheader differs between the two runs.Ruled out locally before filing this: model, reasoning effort, working directory, workspace
roots,
AGENTS.md, installed skills/plugins (reproduces with an emptyCODEX_HOME),sandbox mode, MCP servers, feature flags, auth state, and quota (usage was under 5%).
Every other endpoint returns 200.
Two of my earlier rejections used the cyber-specific message ("This content was flagged for
possible cybersecurity risk ... join the Trusted Access for Cyber program") even though the
blocked prompt was a two-character Chinese greeting. That reads like a classifier with
nothing to classify rather than a genuine content match.
Session/thread ids — diagnostics were uploaded through
/feedback. The latest upload wasattachment-free on purpose, so it did not get swallowed by the attachment rate limit:
Could someone check whether requests carrying this client identifier are routed to a
stricter classifier, and whether the account can be reviewed or cleared? I can supply the
exact A/B command and request ids directly to staff — I would prefer not to post a working
bypass recipe in a public issue.
R3alloc commentedon Sep 15, 2026
Additional account-scoped A/B evidence — still reproducing on 2026-09-15 (≈20h after first observation)
Environment
codex-cli 0.154.0(npm install), Linux x86_64 (RHEL 8.5)CODEX_HOME, same config, switching only the auth material between runs请只输出：8+8=?(trivial arithmetic, Chinese)lowin all four runsResults (2026-09-15 10:40 CST)
gpt-6-astraInvalid prompt: your prompt was flagged as potentially violating our usage policygpt-6-astrasupports_websockets=false)invalid_prompterrorgpt-5.6-sol8+8=16gpt-6-astra9+9=18i.e. the same account succeeds on Sol but fails on Astra, and the same model succeeds on account B but fails on account A. The failure is scoped to the pair (account A ×
gpt-6-astra), deterministically (100% reproducible, several phrasings tried).Response headers captured on the blocked request (account A, HTTP transport)
They look healthy, which is why I don't think this is quota exhaustion or a safety-buffering fallback:
The turn was rejected with
invalid_prompteven thoughprimary-used-percentwas0and the buffering fallback model was still available and unused.Persistence
reasoning effort = highearlier, so it is not tied to a specific effort levelSession id for server-side correlation
Blocked CLI session (run #1 above):
01a0a2ef-dc38-7472-bec4-30e23263b868Happy to share the affected account identifier privately (or run any diagnostic the team wants) — for this account the failure is deterministic, so it should be easy to correlate server-side.
17Reset commentedon Sep 15, 2026
Don't bother anymore—your account has been flagged by risk control. Even if you manage to make a successful request to gpt-5.6-sol, the response will be dumber than usual, and the
Invalid prompterror can't be fixed. Your account is already useless.baochipham942-eng commentedon Sep 16, 2026
Additional account-scoped A/B evidence (2026-09-16, macOS, two ChatGPT accounts, same host):
Clean invocation for all four cells:
codex exec --ephemeral --ignore-user-config --skip-git-repo-check -s read-only -m <model> "Reply only with OK"gpt-6-astraInvalid prompt: your prompt was flagged as potentially violating our usage policygpt-5.6-solOKgpt-6-astraOKgpt-5.6-solOKSame machine, same
codexbinary/version, only the auth material (CODEX_HOME) differs between A and B. This lines up with the account × model scoping other reporters here have already shown (e.g. the two-account same-host A/B above from @R3alloc). Account A also hits the same block outside Codex CLI (Codex Desktop app, identical account).Representative failed thread ID:
01a0a77f-de19-72a0-9073-295e3377f8afWorked around by switching account A's default model to
gpt-5.6-solfor now; also opened a help.openai.com ticket referencing this issue.yuna994 commentedon Sep 25, 2026
I can reproduce this on a personal ChatGPT Pro account using a fresh macOS Codex CLI session, so this is not limited to an existing Desktop task.
Clean CLI reproduction
I resumed the same session and ran /status. It showed the expected Pro account and 87% weekly allowance remaining. The CLI JSON stream and saved transcript did not emit a request_id or response_id for the failed turn.
I also ran codex doctor with normal system network access. Authentication, DNS, WebSocket (HTTP 101), and the ChatGPT inference endpoint all passed. Doctor did report task-inventory inconsistencies (62 missing active rows, 23 missing archived rows, 26 stale rows, and 24 duplicate rollout task IDs), but I cannot establish that these caused the prompt block.
The same account also sees benign prompts rejected in Codex Desktop 26.917.71314 with GPT-6 Astra, GPT-6 Sol, and GPT-6 Luna. /feedback is unavailable in desktop build 10954.
OpenAI Support asked me to add these trace handles for engineering review. Full redacted diagnostic report:
Codex-invalid-prompt-supplemental-diagnostics.pdf
ekichen372 commentedon Sep 27, 2026
I can reproduce the same Astra-specific backend failure on a personal ChatGPT Pro 5x account.
01a0d259-2dda-7ae2-aa88-24319f53dd8d2026-09-24 15:39 GMT+826.917.71314输出 1-10invalid_promptThis appears consistent with the backend-level reproduction documented in this issue. PR #47353 improves the client-side classification of
invalid_prompt, but does not appear to resolve the underlying false-positive rejection. #48713maoming125977-ai commentedon Sep 27, 2026
Additional current macOS reproduction showing that the failure now affects the full GPT-6 Codex family, not only Astra:
0.158.0-alpha.2.1; standalone CLI0.157.1Controlled test conditions: new temporary working directory, ephemeral execution, user config and rules ignored, apps/plugins/multi-agent/daemon disabled, read-only sandbox, low reasoning, and identical complete prompt
1.gpt-6-astrainvalid_promptgpt-6-solinvalid_promptgpt-6-lunainvalid_promptgpt-5.6-solAll GPT-6 failures returned the same message:
The desktop UI reproduced the same result after manually switching among Astra, Sol, and Luna. This comparison makes project context, AGENTS/rules, plugins, the long conversation, reasoning effort, and a general connectivity failure unlikely. It does not establish the internal cause, but is consistent with an account/workspace routing, rollout/entitlement, or false-positive safety classification affecting the GPT-6 family.
No authentication data, account email, private paths, raw sessions, or full logs are included.
NoFearInMyHeart commentedon Oct 8, 2026
Additional account/model-scoped reproduction on macOS:
hi01a11a4a-5dcf-7160-802a-bfcd9edb5d5686b8af7a-0ef7-4891-9d82-91d7103a0629The request reached
https://chatgpt.com/backend-api/codex/responsesover HTTP/SSE and returned HTTP 200 before the stream emittedinvalid_prompt.Control results:
This further supports an account-by-model Codex backend routing or safety-state issue rather than prompt content, local configuration, transport, or general model entitlement. A Help Center escalation is already open with the request ID above.
ocean-wan commentedon Oct 13, 2026
Additional macOS reproduction, still present on 2026-10-13:
0.162.1(Homebrew installation)Darwin 27.0.0 arm64 armopenaiprovidergpt-6.1-solatxhigh;gpt-6-astraathighgpt-5.6-solatxhighThe failure reproduces for neutral prompts such as
helloand你好, in empty directories and in both Codex CLI and Codex Desktop. The exact server error is:I also ran an isolated CLI comparison in an empty temporary directory:
Result:
gpt-6.1-solreturnedinvalid_prompt. The identical invocation withgpt-5.6-solreturned a normal greeting. This makes projectAGENTS.md, user config, plugins/apps, multi-agent tools, skill descriptions, reasoning effort, and prompt wording unlikely causes.Full feedback/log upload thread:
01a13448-ad2e-7c32-a649-7b8e1585e947Please investigate an account/model-routing issue or model-specific safety false positive.