Persistent request/stream failures and safety-check delays blocking authorized infrastructure work

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

Powered by Codex & OWL Versión 26.908.40834 Publicada el 11 sept 2026

What subscription do you have?

chatgpt pro

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

What issue are you seeing?

I am experiencing recurring request execution, streaming, and continuity failures while using OpenAI products for authorized administration of infrastructure that I own and control.

This has already been extensively documented with OpenAI Support under:

• Primary Support Case: 14340855
• Related Support Case: 14511479
• Feedback ID: no-active-thread-01a0937b-c289-7763-8bf0-171c9b624154

The observed failure modes are not limited to a single error and should not be assumed to share one root cause.

Observed behaviors include:

• Requests remaining in a prolonged Thinking / processing state.
• Turns that appear not to start at all.
• Turns producing no visible assistant output.
• Interrupted or lost response streams.
• "Resume stream unavailable".
• "Something went wrong".
• "Thinking stopped".
• "Too many requests".
• "Network connection lost. Trying to reconnect..."
• Repeated cybersecurity "additional checks" on ordinary continuation prompts inside already-established authorized infrastructure-administration conversations.
• Subsequent prompts such as "continue", "AVANCEMOS", or equivalent sometimes also fail to advance the conversation.
• Delayed progress updates and delayed notifications.

One particularly important pattern is that a continuation request may remain unusable for a long period, but later inspection suggests that the turn did not actually perform equivalent amounts of model work. In some cases, the observable behavior is more consistent with the turn never starting, being interrupted before visible output, or losing its stream/session state.

The work context is legitimate administration and development of systems I own or control, including private networking, VMs, MCP services, remote access, application gateways, credentials for my own systems, and automation.

I am not claiming that every symptom is caused by safety routing. The possible failure boundaries include request admission, safety classification, model routing, backend execution, streaming, stream resume, persistence, synchronization, frontend state, rate limiting, and network transport.

The severity is now operational: these failures are blocking the work required to prepare the environment for a HAR capture that OpenAI Support explicitly requested for Case 14340855.

In other words, the product failure is interfering with the diagnostic procedure requested to investigate the same product failure.

Please correlate this Feedback ID with backend/session telemetry if available:

no-active-thread-01a0937b-c289-7763-8bf0-171c9b624154

What steps can reproduce the bug?

Feedback ID: no-active-thread-01a0937b-c289-7763-8bf0-171c9b624154

What is the expected behavior?

A submitted request should have a deterministic observable lifecycle.

At minimum:

• The request should be accepted or rejected explicitly.
• If execution begins, progress/session state should remain consistent.
• If the response stream is interrupted, the client should either resume it successfully or provide a precise terminal error.
• A turn should not silently remain unusable without making clear whether it is queued, executing, failed, rate-limited, safety-reviewed, disconnected, or recoverable.
• Ordinary continuation prompts in an existing authorized infrastructure-administration session should not repeatedly incur extreme delays without a clear terminal state.
• If a cybersecurity safety review is required, the request should either complete within a reasonable bounded period or return a clear actionable status.
• Subsequent prompts should not inherit a broken session/stream state without recovery.
• The desktop client should preserve continuity after a transient transport failure instead of leaving the user with an ambiguous or dead turn.

Most importantly, the product should distinguish failure classes rather than collapsing request-admission, safety review, backend execution, streaming, rate limiting, and connectivity failures into an indistinguishable stalled conversation.

Additional information

This issue has an extensive existing support history.

Primary OpenAI Support Case:
14340855

Related Case:
14511479

Feedback ID:
no-active-thread-01a0937b-c289-7763-8bf0-171c9b624154

OpenAI Support has already acknowledged that:

• substantial diagnostic evidence has been provided;
• Request ID was not available through the UI and the investigation can proceed without it;
• the issue has affected multiple ChatGPT surfaces;
• generic troubleshooting should not simply be repeated;
• previously supplied screenshots and recordings do not need to be resent unless a specific diagnostic gap is identified;
• an additional cybersecurity safety-check notice does not by itself mean that OpenAI determined that the user violated policy.

Support subsequently requested a fresh ChatGPT Web reproduction with a HAR file, the actual conversation URL, timestamp, and timezone.

I am willing to provide that HAR.

However, the reliability failures are currently interfering with the infrastructure/VM/browser setup required to capture it.

Recent evidence includes distinct visible states such as:

"Resume stream unavailable"

"Too many requests"

"Thinking stopped"

"Network connection lost. Trying to reconnect..."

and repeated cybersecurity additional-check notices.

I am deliberately not asserting that all these symptoms share one root cause.

I would specifically ask engineering to correlate this Feedback ID/session with:

• request admission;
• safety classification/routing;
• model dispatch;
• execution start;
• first-token / stream start;
• stream interruption;
• resume attempts;
• persistence;
• client synchronization;
• rate limiting;
• reconnect attempts;
• terminal state.

The most useful answer would be whether the affected turn:

(a) reached execution,
(b) generated output,
(c) opened a stream,
(d) lost that stream,
(e) attempted resume,
(f) was rate-limited or safety-delayed,
or
(g) never actually entered execution.

The problem is now blocking legitimate infrastructure work and also blocking collection of the diagnostic artifact Support requested.

No repository files, tests, or implementation entry points are identified. Start by reproducing the failure in the Codex App and correlating Feedback ID no-active-thread-01a0937b-c289-7763-8bf0-171c9b624154 with request, safety, execution, stream, persistence, rate-limit, and reconnect telemetry. Done requires separating the reported failure classes and providing an actionable terminal state or recovery path.