Do OpenAI Dots Intercept HTTPS? What Is Claimed and What Is Verified

An Ask HN post on October 25, 2026 asks a pointed question: are people aware that OpenAI Dots intercept SSL? The poster says a Dot asked permission to add "the same cloud certificate authority" to a fresh Firefox profile so the browser would trust certificates issued by the cloud proxy. That is a real signal, but it is not yet a documented finding about what OpenAI does with the traffic. This post separates what has been observed from what is being inferred.

If you are new to the product, start with explainx.ai's coverage of OpenAI Dots, the always-on agents announced at DevDay and the earlier safety thread, is ChatGPT Dots safe to leave unattended.

TL;DR: claimed vs verified

What the Ask HN poster describes

The poster, who says they cancelled their OpenAI subscription before the month ended, tried the Dot to test a project in Firefox. The Dot reported that the cloud proxy uses an OpenAI certificate authority that the operating system already trusts, but a fresh Firefox profile does not, and asked whether it could add that authority to the isolated profile. In the Ask HN post, they describe this as interception of web traffic, and worry about users accessing email or other accounts through it.

In a follow-up comment, the same poster (Benjamin_Dobell) adds that on OpenAI's cloud infrastructure OpenAI already has technical access to your data, but argues the approach is the opposite of Codex, which goes to lengths not to upload secrets to the model. That is the real tension: a cloud machine you rent is not the same as a proxy that decrypts everything on it.

What the GitHub issues actually show

Developers using Dots have been filing connectivity bugs on the openai/codex issue tracker. Three observations stand out, all user reports and not OpenAI statements:

1. A proxy-generated certificate. On October 23, 2026, a reporter wrote that, in the ChatGPT/Dot cloud environment, HTTPS requests to an IPv4 literal fail TLS identity checks because the environment's HTTPS proxy returns a proxy-generated leaf certificate signed as OpenAI (O=OpenAI, LLC), not the origin's certificate. The same reporter verified from a separate machine that the origin's own Let's Encrypt certificate was fine, so the mismatch only appears on the cloud proxy path.
2. Named OpenAI authorities in the trust store. In an October 8 report about Firefox and Chrome failing to connect, the reporter lists a public OS certificate inventory that found three pre-existing OpenAI authorities validating against the current trust bundle: Operator Proxy, nebula-dns and CUA MITM. They also say they imported the nebula-dns certificate into Firefox as a website authority, with normal certificate and hostname validation left on.
3. Two network paths. The same issue thread, and a reply from another user dated October 12, describe the agent's execution shell and the GUI terminal behaving differently. In one test the agent shell got a 301 and a 200 from api.github.com while the GUI terminal failed with connection refused, and proxy variables were set in one path and unset in the other.

These reports describe a managed proxy design, not a breach. They do not show what, if anything, is logged.

The Hacker News launch-thread evidence

The Dots launch discussion on Hacker News already had a hands-on test. chen_dev reported fetching gmail.com from the cloud environment with curl and a downloaded Firefox, and seeing a certificate with subject CN=gmail.com issued by O=OpenAI, LLC; CN=openai.com, with verification passing and a 301 redirect to mail.google.com. That is one commenter's account, not a verified result.

A reply from mike_hearn argues the opposite side: the machine runs on OpenAI's own infrastructure, they can already see everything, and central TLS inspection is the right move because agent logs alone would not reveal what a delegated third-party program does, and OpenAI needs to monitor and be able to block agent activity centrally, given agents' past misbehavior online. Both views are opinions of commenters. Neither is OpenAI's position.

Why a proxy like this might exist

Security teams run TLS-inspecting proxies for ordinary reasons. For an always-on agent, a central egress proxy can:

• block requests to destinations OpenAI does not allow, for example abusive posting or spam
• enforce rate limits and domain allowlists
• capture network-level logs when an agent delegates work to a script that the model's own logs would not show
• carry per-user credentials without placing them in the sandbox

That is a plausible story and the commenters above offer a version of it. It is still an inference. The only way to remove the uncertainty is for OpenAI to document what the proxy decrypts, what is logged, who can access the logs, and how long they are kept.

Why it matters for what you put in a Dot

The product pitch for Dots is a personal agent with access to your accounts. That is why the claim matters beyond networking trivia.

The Ask HN poster's second point, that almost everyone using these things may be in violation of workplace policies, is plausible for the work-account case. It is also a reminder that the same question came up for other persistent agents. See explainx.ai's comparison of Dots, Grok Bot, Meta Muse, OpenClaw and Hermes Agent and the analysis of agent privacy promises.

A permission gate in front of a folder, illustrating limits on what an AI agent can reach

What you can check yourself

You can look at the certificate chain from inside your own Dot. From the Dot's terminal, run a command such as openssl s_client -connect example.com:443 -servername example.com and read the issuer line of the leaf certificate. If it says an OpenAI organization instead of a public CA, you are seeing the proxy. Do not disable certificate verification to work around it, and do not copy the OpenAI authority onto a device you own.

Then ask for documentation. Useful questions to send to OpenAI support or to post on the issue tracker:

1. Does the Dots egress proxy terminate and re-sign TLS for all destinations or only some?
2. What is stored, for how long, and who can access it?
3. Is traffic content used for safety review or model training?
4. How should enterprise customers handle accounts that forbid third-party TLS inspection?

What to do now

• Treat the cloud computer as semi-public. Use throwaway or scoped credentials. Prefer API tokens with narrow scopes over account passwords.
• Avoid personal and work logins inside the Dot's browser until OpenAI documents the proxy.
• Keep the CA out of your own machines. Adding an authority that can mint certificates for any domain to a personal browser is a bigger exposure than the Dot itself.
• Review Activity and permission rules for what the agent did.
• Add an independent control layer. AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions. It does not replace OpenAI's own disclosure, but it adds a policy check outside the agent.

For architecture ideas on keeping a persistent agent contained, see explainx.ai's guide to building an always-on persistent AI agent.

What is still unknown

• Whether the proxy sees all HTTPS or only traffic from certain tools.
• Whether decrypted content is retained, and for what purpose.
• Whether the same design applies to every Dot tier and to Windows or Mac clients.
• Whether OpenAI will publish documentation or change the consent prompt that asked to add the authority.

We will update this post if OpenAI publishes a statement.

Related reading

• OpenAI Dots: always-on agents at DevDay
• Is ChatGPT Dots safe to leave unattended?
• AI agent privacy promises: Meta Muse and OpenAI Dots
• Dots vs Grok Bot vs Meta Muse vs OpenClaw vs Hermes Agent
• How to build an always-on persistent AI agent
• Apple Full Disk Access and AI agents

Details are accurate as of October 25, 2026 and based on user reports. OpenAI had not published a description of the proxy in the sources reviewed.