gpt-6-astra/low repeatedly hits cyber_policy during benign bug triage; Sol continuation unaffected

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

Incident session: Codex core 0.154.0-alpha.6.2, originator Codex Desktop. Linux package metadata at collection time: codex-desktop 2026.09.14.190251-1.fc41.x86_64. Current CLI: codex-cli 0.154.0. OpenCodex proxy at the incident: 2.55.0, running on Bun 1.4.2 x64.

The rollout captures the core version but not a separate About-dialog display string, so I am reporting the installed Desktop package version with its source rather than guessing an upstream marketing version.

What subscription do you have?

ChatGPT Pro. The current Codex usage API returned planType: "pro" at collection time. This incident's proxy export did not observe subscriptionPlan, entitlementSource, cyberAccessStatus, or modelAccessStatus, so the effective entitlement applied to these five Astra requests remains a backend question. No account identifier is included in the report.

What platform is your computer?

Fedora Linux 44, x86_64. uname -mprs:

Linux 7.2.4-200.fc44.x86_64 x86_64 unknown

What issue are you seeing?

Five distinct root turns using gpt-6-astra at low reasoning effort terminated with cyber_policy while coordinating ordinary bug triage and remediation in my public repository. The same task then continued on gpt-5.6-sol at high effort without any observed cyber_policy event: through the evidence cutoff, OpenCodex recorded 74 exact-thread Sol rows, all status 200, including 63 terminal completions and 11 rows with no terminal status.

This appears to be repeated false-positive classification, not a request to bypass a safety control. The work was repository maintenance: taking over an existing public bug campaign, validating reported bugs with bounded/private fixtures and source inspection, grouping related bugs under shared owners, reviewing plans, and proceeding toward fixes and CI.

• Task title: Triage all open bugs
• Task: codex://threads/01a0a229-2c49-7271-ae86-98ffee1f4b22
• Thread ID: 01a0a229-2c49-7271-ae86-98ffee1f4b22
• Public repository: https://github.com/donadiosolutions/lcm
• Public campaign Epic: https://github.com/donadiosolutions/lcm/issues/968
• Reviewed diagnostic evidence: https://gist.github.com/bcdonadio/309b136e71457d45e08884cfba77c167

The refusals repeatedly stopped the root coordinator without a final response, forcing manual continuation and eventually a model switch. Some failed requests emitted partial output events first, but none produced a final response.

Related open reports describe the same general Astra symptom in different tasks and versions: #43131 and #42906. This report has a different exact task identity, five new turn IDs, five new upstream response IDs, a newer core/proxy pair, and a same-task Sol comparison.

Recorded refusals

All times are on 2026-09-14. Local time is America/Sao_Paulo (UTC−03:00).

#	Failure time (UTC)	Local time	Failed turn ID	Model / effort	Root-turn duration	Terminal
1	23:17:58.031Z	20:17:58.031−03:00	01a0a229-33a6-7ee2-a813-6e3605665d90	gpt-6-astra / low	873,674 ms	cyber_policy
2	23:20:29.772Z	20:20:29.772−03:00	01a0a236-dcd9-7e20-8564-8c5c95659c4f	gpt-6-astra / low	130,148 ms	cyber_policy
3	23:28:25.922Z	20:28:25.922−03:00	01a0a23a-6692-7590-a770-24988c24c050	gpt-6-astra / low	374,434 ms	cyber_policy
4	23:29:19.348Z	20:29:19.348−03:00	01a0a240-6b38-7c23-8019-1f08cdf11cc1	gpt-6-astra / low	33,453 ms	cyber_policy
5	23:32:14.052Z	20:32:14.052−03:00	01a0a241-12a8-7b80-8fc1-e26dfb1c84f2	gpt-6-astra / low	165,291 ms	cyber_policy

Every Codex task_complete recorded this exact error:

This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber

Direct OpenCodex correlation

The canonical OpenCodex ledger directly recorded the exact Codex root thread and failed turn on each request. Each row below is a distinct request, one physical upstream send, no retry or provider fallback, requested/resolved/forwarded model gpt-6-astra, wire effort low, and terminal response.failed with cyber_policy.

#	Failed turn	Local request	Exact failed upstream response	Previous response sent	Proxy duration	Output before failure
1	…5d90	ocx-74b8b17e43020313cb34ef9f0d537da3	resp_02a882b2fe0f43f8016aa88090416487d281462abfa7f9ac32	resp_0dd9da22f9d70ece016aa88082456087d29edab45abc2b3da7	22,234 ms	output item observed; no text delta / first-output time recorded
2	…9c4f	ocx-7bd55ffc5f8faaf4338d6fe2abadd0ca	resp_0f4ed47bd1ebebe6016aa8812a681087d281552414b8dfc3ec	none	20,323 ms	yes; first output 7,691 ms
3	…c050	ocx-6cf949ad3cd74b1e0303422cd235a6ec	resp_01c989a2f23f50b9016aa882fdfb8c87d2a2762e36f6dd1608	resp_0adef71773ad26da016aa882ebe6f087d2bc3e12f9d98abbeb	28,782 ms	output item observed; no text delta / first-output time recorded
4	…1cc1	ocx-69eef4e28f44fdd46994770299a274a7	resp_02d45e6ed4e1732c016aa88331e54087d2a4285e2353eb0b23	none	31,069 ms	yes; text deltas, first output 7,220 ms
5	…84f2	ocx-dba49bcd24de546f4321d59c21182cc1	resp_0fedcfe5ecdf1e30016aa883e8964887d2b3d246e8af07e51c	resp_0a029ee73383e3cf016aa883da91c087d29d6a8de3009f9224	21,957 ms	yes; first output 9,523 ms

No separate upstream HTTP request ID was observed for these WebSocket requests. The exact local transaction, attempt, and send IDs are in exact-correlation.json in the evidence gist.

Important ID boundary: the Codex token-usage response_id for a failed turn is not generally the failed upstream response. In turns 1, 3, and 5 it identifies the predecessor response; turn 2 has a different local token-usage response ID despite no previous_response_id on the failed full-input request; turn 4 has no local token-usage response ID. The evidence keeps those fields separately labeled.

Workflow and prompt/tool context

The initial user request, with only the private filesystem path normalized, was:

[$triage-fix-all-bugs](/[REDACTED_PATH]/SKILL.md) Steal all the open bugs from the previous campaign.

Additional exact user messages before the first refusal were:

Merge similar bugs into a single bug owner, please.
If you're having issues with cgroups limits, raise them.

The four later failed turns were continuations: Please attempt to continue., Please continue., continue, and a turn containing continue followed by Please continue..

The selected visible chronology in codex-evidence.json intentionally preserves context that might affect classification rather than presenting an artificially flattering summary. Before the first refusal, the coordinator disclosed that a historical triage had used prohibited busy-loop load generation, confirmed those old processes were gone, and stated that current work was limited to isolated probes and deterministic tests. Later visible messages showed the coordinator completing all pending triage, grouping related sanitizer/journal/token bugs, starting independent plan reviews, and preparing bounded implementation and CI work.

The visible tool boundary consisted primarily of bounded shell/source-inspection calls and multi-agent coordination (spawn_agent, messages, waits). Raw tool arguments/results, local path inventories, encrypted delegated prompts, hidden instructions, reasoning, credentials, and unrelated task content are not published. The selected transcript artifact contains exact relevant visible messages plus tool-kind counts; it is not asserted to be the complete failed wire payload.

Expanded proxy facts

All five failures used the OpenAI Responses adapter over WebSocket. The WebSocket handshake succeeded with status 101, after which the stream produced response.failed; OpenCodex mapped the terminal result to 400. upstreamRequestAccepted was true. Authentication route was forward. Usage was not reported for any of the failed requests.

#	Inbound → forwarded items	Request → forwarded bytes	Replayed / reconstructed items	Forwarded messages / calls / results / encrypted
1	4 → 175	8,245 → 642,503	171 / 175	23 / 49 / 49 / 49
2	208 → 209	728,765 → 717,414	0 / 208	26 / 54 / 54 / 65
3	3 → 284	7,419 → 875,332	281 / 284	30 / 68 / 68 / 98
4	284 → 285	880,388 → 864,920	0 / 284	31 / 68 / 68 / 98
5	2 → 319	5,239 → 916,369	317 / 319	35 / 76 / 76 / 112

The alternating full-input and previous-response continuation shapes both failed. This is evidence about request shape, not a claim that replay, any particular phrase, or the last adjacent tool caused the policy decision.

Same-task Sol comparison (no Sol refusal)

After the fifth Astra failure, settings changed and a new root turn started at 2026-09-14T23:32:30.213Z on gpt-5.6-sol / high. The first exact-thread Sol request arrived at 23:32:33.036Z and completed with status 200 in 6,757 ms, upstream response resp_0027d60499ac5910016aa884129a9087d29d673cdbc1de0011.

At the fixed comparison cutoff 2026-09-14T23:53:44.926Z, OpenCodex had 74 exact-thread Sol rows across two later root turns:

• 63 status-200 terminal completions;
• 11 status-200 rows with no terminal status;
• zero cyber_policy codes;
• zero other error codes.

Codex's later task API showed both Sol turns as interrupted with error: null, not policy-failed. Visible messages confirm that Sol continued the same campaign, interacting with the existing owners and moving from plan review into bounded implementation/test allocation. Three representative successful Sol records are included in the native proxy export.

This is a same-task workflow comparison, not a byte-identical control: Astra used low effort, Sol used high, and the accumulated context/request payload evolved. It supports a model-specific discrepancy worth investigating but does not by itself prove the backend cause.

What steps can reproduce the bug?

This is a recorded historical sequence. I did not deliberately provoke another refusal after collection.

1. In Codex Desktop, select gpt-6-astra with low reasoning effort for a root coordinator in a public repository.
2. Ask it to take over an existing bug-triage campaign, verify pending bugs with bounded source inspection/private fixtures, group related bugs under shared owners, and proceed to reviewed fixes and CI.
3. While it is making progress, send ordinary continuation messages such as Please attempt to continue., Please continue., or continue.
4. In this task, five separate root turns eventually ended with task_complete.error.codex_error_info = "cyber_policy", including two short continuation turns. Each had one directly matched Astra upstream request that ended in response.failed.
5. Switch the same task to gpt-5.6-sol / high and continue the same bug campaign. In the observed post-switch window, the work continued across 74 exact-thread status-200 proxy rows with no cyber_policy event.

I have not established whether a fresh new task reproduces deterministically, whether low vs high effort matters independently of the model, or which specific accumulated context item influenced classification.

What is the expected behavior?

Authorized repository maintenance and bug triage should proceed without apparent false-positive cyber_policy terminations. Policy treatment should be consistent and should apply the correct account/model entitlement. If a request is blocked, the client/support evidence should retain enough backend correlation data—especially the actual failed response/policy event identity—to diagnose the decision without repeated manual retries.

Please investigate the five exact upstream response IDs above; this report is requesting classification/entitlement diagnosis, not a policy bypass.

Additional information

Evidence gist: https://gist.github.com/bcdonadio/309b136e71457d45e08884cfba77c167

The gist contains:

• codex-evidence.json: narrow, reviewed Codex failure chronology and selected transcript excerpts;
• proxy-export.json: native sanitized OpenCodex export for five failures, three predecessor successes, and three Sol successes;
• exact-correlation.json: actual support IDs that the native export pseudonymizes;
• sol-comparison.json: fixed-cutoff aggregate and representative Sol rows;
• evidence-guide.md: provenance, coverage, omissions, redactions, and SHA-256 manifest.

The native export contains all 11 requested records and zero omitted selected records, but marks completeness partial because routeDecision.candidates was projection-omitted. policyEventId, traceId, effective subscription/entitlement fields, model-access/switch fields, and billed-usage source were unavailable. Record capture was truncated, so I am not claiming to have the full wire payload or causal policy trigger. Service-restart state within the export window is unknown.

The public artifacts were manually and independently secret-reviewed. They contain no account UUID, credentials, authorization headers, cookies, API keys, hidden platform instructions, private reasoning, or ciphertext. Exact diagnostic UUIDs and response IDs are retained intentionally for support lookup.

Useful backend questions:

1. What policy event/rule produced cyber_policy for each of the five exact failed response IDs?
2. Which subscription/Cyber/model-access entitlement was applied to those Astra requests?
3. Why did Astra/low repeatedly fail while Sol/high continued the same root task without a policy event?
4. Did accumulated replay/context shape affect classification, and can that be distinguished from the adjacent continuation prompt?
5. Can future response.failed records expose a stable, safe policyEventId or trace ID for support correlation?

Start with codex-evidence.json and exact-correlation.json in the linked evidence gist, then compare the five Astra response.failed/cyber_policy records with the successful Sol records and the OpenAI Responses WebSocket adapter context. The payload names no repository file, test, or entry point to edit. Done means establishing the failure boundary and whether a client-side fix is possible, or documenting that remediation requires backend policy investigation.