Diagnostic for remote compaction stream disconnects: test long-idle HTTPS path with slee.pt >90s

We now have a reproducible way to diagnose one important class of remote compact failures.

This does not prove that every /responses/compact failure is caused by the client network path, but it does provide a strong self-test for the specific case where compaction fails after a long silent wait and then reports:

Error running remote compact task: stream disconnected before completion:
error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

The key observation is that /responses/compact may spend a long time server-side before returning a final response. If some proxy, tunnel, gateway, or upstream path closes long-idle HTTPS requests before the response arrives, Codex will surface exactly this kind of failure.

A simple way to test that path is to use slee.pt, which intentionally waits before replying:

• docs: https://slee.pt/
• alternate delay endpoint: https://slee.pt/api/delay?time=90s

What matters here is not average latency. What matters is whether a long-lived HTTPS request with no response bytes for >90s can survive and eventually return normally.

Minimal test

Direct path:

curl -sS --max-time 180 "https://slee.pt/api/delay?time=90s"

Or the documented POST form:

curl -sS --max-time 180 -X POST "https://slee.pt/90s" \
  -H "Content-Type: application/json" \
  -d '{}'

If you normally use a local proxy, test the exact same request through that proxy too:

curl -sS --proxy http://127.0.0.1:PORT --max-time 180 "https://slee.pt/api/delay?time=90s"

or

curl -sS --proxy http://127.0.0.1:PORT --max-time 180 -X POST "https://slee.pt/90s" \
  -H "Content-Type: application/json" \
  -d '{}'

How to interpret it

If the request returns successfully after about 90 seconds with valid JSON, then that network path can preserve a long-idle HTTPS request correctly.

If it gets cut off before the delayed response arrives, then some hop between the local machine and the network path is terminating long-idle connections. That is directly relevant to automatic compaction failures, because remote compaction can sit silent long enough to trigger the same behavior.

In other words:

• slee.pt >90s succeeds: this specific idle-connection failure mode is less likely on that path
• slee.pt >90s gets cut off early: there is a transport/proxy/gateway timeout on the path, and that is strongly correlated with remote compact failures

This does not rule out separate server-side compaction bugs, but it does give users a concrete way to distinguish "Codex service bug" from "my local/network path cannot hold a long silent request open long enough".

A practical implication: if a user can reproduce an early cutoff with slee.pt on the same path they use for Codex, then blaming /responses/compact alone is technically incomplete. The transport path is demonstrably unable to preserve the kind of long silent HTTPS request that remote compaction depends on.