[macOS][GPT-5.6 Sol] Live ChatGPT Desktop hold exposes protectionType=cyber while renderer fetch remains native

Product / environment

• Surface: ChatGPT Desktop ordinary chat on macOS (Apple Silicon)
• Model: GPT-5.6 Sol, high/xhigh reasoning
• Observed: 2026-09-07 00:55:07 UTC
• This report is about an additional safety-check false positive / observability problem, not a request to bypass safeguards.

Summary

During a legitimate local engineering/debugging workflow, ChatGPT Desktop displayed the native additional-processing banner:

Before responding, our systems are taking additional time to process this request. You can retry with a faster model for a quicker response, though it may be less capable of handling complex requests.

While that banner was still live, I captured a read-only renderer snapshot from the same desktop process. React Fiber props on the native status component reported:

protectionType = "cyber"

The same snapshot also captured the backend correlation request ID:

164dc01a-1e11-4da6-ae5d-1aeb57ddbbd1

This appears to be the same family of false-positive cyber safety checks reported in #19533, #28066, #34913, #37473, #37834, and #40970, but this report adds a direct live correlation between the visible banner and the component's protectionType value.

Important local-control elimination evidence

At the same instant the native banner was visible and protectionType="cyber" was read back:

window.fetch.toString() == "function fetch() { [native code] }"
custom stream coalescer active = false
custom performance guard active = false
local HTTP/HTTPS system proxy = off
local MITM listener = absent
ChatGPT process proxy/SOCKS environment variables = absent

The renderer's only relevant custom symbol was a display-only progress overlay. Its runtime counters were:

blockingDependencies = 0
gateWaitCount = 0
nativeDomWriteCount = 0
nativeStructuralMutationCount = 0

So this particular hold was not produced by a local fetch wrapper, SSE coalescer, proxy, or tool gate. The native OpenAI-owned status component itself carried protectionType="cyber".

Repetition / tool correlation

A local observer log contains 24 historical occurrences of the same native banner. For 11 of the 24, there was no Remote Desktop Commander tool activity in the preceding 120 seconds. This is important because it argues against treating local shell/MCP use as a necessary trigger.

Conversely, among 825 recorded start_process tool calls, only 18 were followed by a hold within 30 seconds (~2.2%). read_file was ~2.1% over the same window. Generic shell activity therefore does not appear to be a specific or sufficient cause.

Expected behavior

1. Legitimate local software engineering should not be repeatedly classified as cyber merely because the conversation contains tool/process/configuration vocabulary.
2. If an additional safety check is required, the UI should continue showing recoverable progress instead of making a long-running task look stalled.
3. Every safety-check banner should expose a stable request/correlation ID directly to the user so false positives can be reported without renderer inspection.
4. A false-positive reporting path should preserve the selected model/reasoning level and completed tool state.

Requested investigation

Please correlate request ID 164dc01a-1e11-4da6-ae5d-1aeb57ddbbd1 with backend classifier telemetry and review whether the cyber classification was appropriate.

If this is a false positive, please use the event for classifier tuning. An earlier OpenAI maintainer response on #19533 stated that these reports help tune the classifier.

I can provide additional redacted timestamps, event envelopes, hashes, and a private evidence packet if maintainers need them. I am intentionally not publishing account identifiers, device IDs, local absolute paths, credentials, cookies, or raw conversation contents.

Start by correlating request ID 164dc01a-1e11-4da6-ae5d-1aeb57ddbbd1 with backend classifier telemetry and reviewing the native status component's protectionType value. Done means determining whether the cyber classification was a false positive and recording the result for classifier tuning or follow-up.