codex-oauth-plus-onboarding-skill/references/openai-chatgpt-browser-probe-2026-05-08.md

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:

/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:

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:

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:

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.