# OpenAI/ChatGPT Browser Probe Notes — 2026-05-08

Session-specific learning from testing the Codex OAuth automation browser path on BOSS's Mac.

## Symptoms observed

- `https://openai.com/` loaded successfully in a real visible Chrome profile.
- `https://chatgpt.com/` failed before the registration/auth flow:
  - First failure in Chrome: `NET::ERR_CERT_COMMON_NAME_INVALID` / privacy error.
  - Relaunching Chrome with `--ignore-certificate-errors` bypassed the cert interstitial, but then failed with `ERR_CONNECTION_CLOSED`.
  - Terminal probe also failed: `curl -I -L https://chatgpt.com/` returned `LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to chatgpt.com:443`.
- `https://openai.com/` via curl returned Cloudflare challenge/403 in one probe, while the visible browser still rendered the OpenAI page.

## Interpretation

Treat this as a network/proxy/TLS path issue before treating it as an extension automation bug. If `chatgpt.com` cannot complete TLS/HTTP loading in the same environment, steps that open ChatGPT or OpenAI Auth will fail regardless of sidepanel settings.

## Probe sequence to reuse

1. Launch an isolated Chrome profile with remote debugging and the unpacked extension, but do not start registration yet:

```bash
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --user-data-dir="$PROFILE_DIR" \
  --remote-debugging-port=9228 \
  --disable-extensions-except="$CODEX_OAUTH_EXTENSION_DIR" \
  --load-extension="$CODEX_OAUTH_EXTENSION_DIR" \
  --no-first-run \
  --no-default-browser-check \
  --new-window https://openai.com/
```

2. Verify CDP is reachable:

```bash
curl -s http://127.0.0.1:9228/json/version
curl -s http://127.0.0.1:9228/json
```

3. Check direct network path before blaming DOM automation:

```bash
curl -I -L --max-time 15 https://chatgpt.com/
curl -I -L --max-time 15 https://openai.com/
```

4. If Chrome shows `NET::ERR_CERT_COMMON_NAME_INVALID` for `chatgpt.com`, pause the OAuth run and fix proxy/TLS/mitm path first. `--ignore-certificate-errors` can be used only as a diagnostic; it is not a real fix because the next failure may still be `ERR_CONNECTION_CLOSED`.

## PassWall2 DNS/prerequisite follow-up

After BOSS updated PassWall2 AI split rules, the browser path was still blocked because DNS was not cleanly taken over by remote/proxied DNS:

- `curl -I -L --max-time 20 https://chatgpt.com/` still failed with `LibreSSL SSL_connect: SSL_ERROR_SYSCALL`.
- Visible Chrome still ended on `chrome-error://chromewebdata/` with `ERR_CONNECTION_CLOSED`, and stderr continued to show `ssl_client_socket_impl.cc:924 ... net_error -100`.
- macOS system resolver returned polluted/suspicious answers:
  - `chatgpt.com -> 199.59.150.40` plus IPv6 `2a03:2880:...` (Twitter/Facebook-looking ranges, not expected Cloudflare/OpenAI path)
  - `accounts.openai.com -> 128.121.146.109` plus IPv6 `2001::80f2:f09b`
- A DoH comparison for `chatgpt.com` via Cloudflare showed expected Cloudflare-style A records such as `104.18.32.47` and `172.64.155.209`, confirming local DNS pollution.
- `scutil --dns` showed local macOS DNS included ISP/public resolvers such as `2400:3200::1`, `2402:4e00::`, `114.114.114.114`, and `8.8.8.8`; do not assume PassWall2 domain split rules alone mean DNS is being intercepted.

Operational rule: if `chatgpt.com` or `accounts.openai.com` resolves to non-Cloudflare/Twitter/Facebook-looking addresses, stop. Ask BOSS to fix PassWall2 DNS takeover / remote DNS / fake-ip or redir-host settings before testing extension automation. Do not proceed to registration/OAuth while Chrome still shows `ERR_CONNECTION_CLOSED`.

Helpful probe snippet:

```bash
python3 - <<'PY'
import socket
for host in ['chatgpt.com','accounts.openai.com','auth.openai.com','openai.com']:
    try:
        print(host, sorted({x[4][0] for x in socket.getaddrinfo(host,443,proto=socket.IPPROTO_TCP)}))
    except Exception as e:
        print(host, 'ERR', e)
PY
scutil --dns | sed -n '1,120p'
curl -I -L --max-time 20 https://chatgpt.com/
```


Before sending `SAVE_SETTING` / `AUTO_RUN` programmatically, verify:

- `chrome://extensions/` shows `codex-oauth-automation-extension` loaded.
- The target URL/extension ID corresponds to the unpacked repo, not a built-in/other extension.
- The target context exposes the expected Chrome extension APIs and/or the sidepanel route is usable.

If `chrome://extensions/` shows no unpacked extension despite `--load-extension`, relaunch with a fresh profile and inspect Chrome stderr/profile policy before proceeding.