docs: sync latest codex oauth onboarding skill

2026-05-08 21:13:53 +08:00
parent 368a5948b2
commit 9102557f8e
9 changed files with 579 additions and 9 deletions
@@ -0,0 +1,62 @@
+# ClawEmail Prefix Probe Notes — 2026-05
+
+Context: During Codex OAuth registration testing for BOSS, we needed fresh ClawEmail sub-mailboxes and discovered live API constraints stricter than public docs.
+
+## Official/public expectation
+
+Docs/help say `mail-cli clawemail create --prefix <prefix> --type sub` accepts 1-64 characters and examples mention `bot1`, `bot.v1`, `my-agent`, `support`.
+
+## Live observed behavior
+
+Using BOSS's primary `chickliu@claw.163.com`, successful sub-mailbox shape is:
+
+```text
+chickliu.<prefix>@claw.163.com
+```
+
+Probed prefixes were created and immediately deleted when successful.
+
+Accepted examples:
+
+- `a`, `ab`, `abc`, `bot`, `bot1`, `test`, `codex`, `oauth`
+- `codexabcdef` (11 chars) accepted
+- random lowercase lengths 1-11 accepted
+- digit suffix examples like `codex12345` accepted
+
+Rejected examples:
+
+- length 12+ such as `codexabcdefg`, `xxxxxxxxxxxx`
+- dot/hyphen examples: `a.b`, `bot.v1`, `my-agent`, `abc.def`
+
+Observed practical rule:
+
+```text
+^[A-Za-z0-9]{1,11}$
+```
+
+## BOSS preference for Codex/OAuth runs
+
+BOSS corrected the desired mailbox shape: after the dot, use **only 8 lowercase English random letters**, with no `cod`/`codex` fixed prefix.
+
+Example:
+
+```text
+chickliu.ktqcxzux@claw.163.com
+```
+
+Env policy used locally:
+
+```text
+CLAWEMAIL_PREFIX=
+CLAWEMAIL_RANDOM_SUFFIX_LENGTH=8
+CLAWEMAIL_RANDOM_SUFFIX_CHARSET=abcdefghijklmnopqrstuvwxyz
+CLAWEMAIL_PREFIX_WITH_RANDOM_SUFFIX=true
+```
+
+When a helper does not support empty base prefix + suffix policy, generate the full 8-letter create prefix yourself and pass it directly:
+
+```bash
+mail-cli clawemail create --prefix "$RANDOM_8_LOWERCASE" --type sub --display-name "Codex OAuth $RANDOM_8_LOWERCASE" --json
+```
+
+Record every created mailbox in the local JSONL record file with status `pending`, then update to `success`, `failed_*`, or `deleted_replaced`.
@@ -0,0 +1,49 @@
+# Codex onboarding ClawEmail random suffix policy — 2026-05-08
+
+BOSS corrected the mailbox policy during a Codex OAuth registration test:
+
+- Use **only 8 lowercase English random letters** as the ClawEmail create prefix.
+- Do not prepend `cod`, `codex`, or another business marker unless explicitly requested.
+- Desired visible mailbox shape:
+
+```text
+chickliu.<8 lowercase random letters>@claw.163.com
+```
+
+Example created successfully in-session:
+
+```text
+chickliu.ktqcxzux@claw.163.com
+```
+
+## Why not `codex` + 8 letters?
+
+The live ClawEmail Open API rejected create prefixes of length 12+ with `OPEN_API_1003 prefix format is invalid`, despite public docs/help saying 1-64 characters. The real accepted maximum observed was 11 characters. Since `codex` + 8 letters is 13 characters, it fails.
+
+A temporary `cod` + 8-letter scheme created `chickliu.coddwrkviby@claw.163.com`, but BOSS clarified they want the dot-suffix itself to be only the 8 random letters. That temporary mailbox was deleted and replaced.
+
+## Env policy
+
+For this workflow, use:
+
+```bash
+CLAWEMAIL_PREFIX=
+CLAWEMAIL_RANDOM_SUFFIX_LENGTH=8
+CLAWEMAIL_RANDOM_SUFFIX_CHARSET=abcdefghijklmnopqrstuvwxyz
+CLAWEMAIL_PREFIX_WITH_RANDOM_SUFFIX=true
+```
+
+If helper scripts do not support these fields, generate the prefix directly in the runner:
+
+```python
+import random, string
+prefix = ''.join(random.choice(string.ascii_lowercase) for _ in range(8))
+```
+
+Then call:
+
+```bash
+mail-cli clawemail create --prefix "$prefix" --type sub --display-name "Codex OAuth $prefix" --json
+```
+
+Record created mailboxes in the configured `CLAWEMAIL_RECORD_FILE`, mark them `pending`, and update to `deleted_replaced`, `success`, or `failed` as the run proceeds.
@@ -0,0 +1,57 @@
+# Codex OAuth env handling notes
+
+Session-derived operational notes for `codex-oauth-plus-onboarding`.
+
+## Sensitive template cleanup workflow
+
+If BOSS temporarily writes real values into the skill template at:
+
+```text
+~/.hermes/skills/software-development/codex-oauth-plus-onboarding/templates/codex_oauth_onboarding.env.example
+```
+
+use this sequence:
+
+1. Copy the current template to the real local env file:
+   ```bash
+   mkdir -p ~/.hermes/env
+   chmod 700 ~/.hermes/env
+   cp -p ~/.hermes/skills/software-development/codex-oauth-plus-onboarding/templates/codex_oauth_onboarding.env.example \
+     ~/.hermes/env/codex_oauth_onboarding.env
+   chmod 600 ~/.hermes/env/codex_oauth_onboarding.env
+   ```
+2. Back up the original filled template to a private workspace backup before sanitizing:
+   ```bash
+   TS=$(date '+%Y%m%d_%H%M%S')
+   mkdir -p ~/.Hermes/workspace/codex-oauth/env-backups
+   cp -p ~/.hermes/skills/software-development/codex-oauth-plus-onboarding/templates/codex_oauth_onboarding.env.example \
+     ~/.Hermes/workspace/codex-oauth/env-backups/codex_oauth_onboarding.env.example.with-values_$TS
+   chmod 600 ~/.Hermes/workspace/codex-oauth/env-backups/codex_oauth_onboarding.env.example.with-values_$TS
+   ```
+3. Sanitize the template back to placeholders/defaults. Remove real target URLs, API keys, passwords, proxy server, phone numbers, ClawEmail UID, and account password. Keep only safe defaults such as Chrome path, browser profile root, booleans/timeouts, record-file paths, and example comments.
+4. Verify no obvious sensitive residues remain:
+   ```bash
+   grep -nE '\*\*\*|\.\.\.|=[0-9]+\||chickliu|135601|192\.168\.2\.|socks5://[^h]|eyJhbGci|admin|password|token|key' \
+     ~/.hermes/skills/software-development/codex-oauth-plus-onboarding/templates/codex_oauth_onboarding.env.example || true
+   ```
+   Review matches manually; example comments like `socks5://host:port` are OK.
+
+## 5sim field mapping
+
+When BOSS provides 5sim config in JSON/camelCase form, map it into env keys as:
+
+```bash
+fiveSimApiKey       -> FIVE_SIM_API_KEY
+fiveSimBaseUrl      -> FIVE_SIM_BASE_URL
+fiveSimCountryOrder -> FIVE_SIM_COUNTRY_ORDER=argentina,netherlands,indonesia
+fiveSimOperator     -> FIVE_SIM_OPERATOR=any
+fiveSimProduct      -> FIVE_SIM_PRODUCT=openai
+```
+
+For compatibility with older extension naming, also set:
+
+```bash
+FIVE_SIM_SERVICE=openai
+```
+
+Do not echo the full JWT/API key in final replies; show only `[REDACTED]` or a short prefix/suffix if verification needs it.
@@ -0,0 +1,85 @@
+# 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.
@@ -0,0 +1,94 @@
+# OpenAI/ChatGPT Proxy Endpoint Probe Notes — 2026-05-08
+
+## Context
+
+During Codex/OpenAI OAuth prerequisite testing, BOSS asked to verify direct browser access and then explicit LAN proxy endpoints:
+
+- `socks5://192.168.2.8:1085` (tested as `socks5h://` so DNS resolves through proxy)
+- `http://192.168.2.8:1084`
+
+The Mac had local IP `192.168.2.69/24`, default route via `192.168.2.8`, and an ARP entry for `192.168.2.8`, but ICMP/TCP to the gateway/proxy endpoint failed.
+
+## Observed failure signatures
+
+System/browser without working proxy:
+
+```text
+chatgpt.com -> polluted IPs such as 202.160.128.16 / 199.59.150.40 / 2a03:2880:...
+accounts.openai.com -> polluted IPs such as 192.133.77.189 / 128.121.146.109 / 2a03:2880:...
+Chrome: ERR_CONNECTION_CLOSED
+curl: LibreSSL SSL_connect: SSL_ERROR_SYSCALL
+```
+
+Explicit SOCKS5/HTTP proxy endpoint unavailable:
+
+```text
+ping 192.168.2.8 -> sendto: No route to host / 100% packet loss
+nc -vz -w 5 192.168.2.8 1085 -> No route to host
+curl --proxy socks5h://192.168.2.8:1085 https://chatgpt.com/ -> Failed to connect
+nc -vz -w 3 192.168.2.8 1084 -> No route to host
+curl --proxy http://192.168.2.8:1084 https://chatgpt.com/ -> Failed to connect
+```
+
+Route/ARP could still look superficially valid:
+
+```text
+default gateway: 192.168.2.8
+192.168.2.8 at <mac> on en0 ifscope
+local IP: 192.168.2.69
+```
+
+Do not mistake this for a ChatGPT/OpenAI auth bug or extension bug. If the LAN proxy endpoint itself is unreachable, browser automation and OAuth should stop.
+
+## Recommended probe order
+
+1. Flush DNS cache only as a low-risk refresh:
+
+```bash
+dscacheutil -flushcache || true
+killall -HUP mDNSResponder 2>/dev/null || true
+```
+
+2. Check current DNS and detect pollution:
+
+```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
+```
+
+3. Test gateway and proxy endpoint before browser tests:
+
+```bash
+ping -c 2 -W 1000 192.168.2.8 || true
+nc -vz -w 5 192.168.2.8 1085 || true
+nc -vz -w 5 192.168.2.8 1084 || true
+```
+
+4. For SOCKS5, use `socks5h://` in curl so DNS is performed through the proxy:
+
+```bash
+curl --proxy socks5h://192.168.2.8:1085 -I -L --max-time 30 https://chatgpt.com/
+curl --proxy socks5h://192.168.2.8:1085 --max-time 20 https://api.ipify.org
+```
+
+5. For HTTP proxy:
+
+```bash
+curl --proxy http://192.168.2.8:1084 -I -L --max-time 30 https://chatgpt.com/
+curl --proxy http://192.168.2.8:1084 --max-time 20 https://api.ipify.org
+```
+
+6. Only launch a proxied browser or extension run after at least one proxy endpoint succeeds.
+
+## Interpretation
+
+- `No route to host` to the proxy IP/port means the local Mac cannot reach the LAN proxy service. Fix LAN/gateway/firewall/Wi‑Fi/VLAN/router first.
+- `Connection refused` means the host is reachable but no service is listening on that port or firewall actively rejects it.
+- HTTP 200/30x/403 Cloudflare challenge through the proxy is better than transport failure; browser testing can proceed, but CAPTCHA/security challenge may still require manual action.
+- Polluted system DNS may remain even while explicit `socks5h://` works; in that case use browser `--proxy-server=socks5://...` or ensure PassWall2 DNS hijack/remote DNS is correctly applied.
@@ -0,0 +1,72 @@
+# OpenAI/ChatGPT DNS Pollution Probe — 2026-05-08
+
+Context: after BOSS updated PassWall2 AI/OpenAI分流规则, browser automation still could not proceed because the local macOS resolver was still returning polluted IPs for key ChatGPT/Auth domains.
+
+## Observed failure pattern
+
+System resolver results:
+
+```text
+chatgpt.com -> 199.59.150.40, 2a03:2880:f10c:83:face:b00c:0:25de
+accounts.openai.com -> 128.121.146.109, 2001::80f2:f09b
+auth.openai.com -> 104.18.41.241, 172.64.146.15, Cloudflare IPv6
+openai.com -> 104.18.33.45, 172.64.154.211
+```
+
+`chatgpt.com` and `accounts.openai.com` above are polluted / wrong for the flow. Browser and curl failed before automation could start:
+
+```text
+curl https://chatgpt.com/ -> LibreSSL SSL_connect: SSL_ERROR_SYSCALL
+curl https://accounts.openai.com/ -> LibreSSL SSL_connect: SSL_ERROR_SYSCALL
+Chrome -> ERR_CONNECTION_CLOSED / net_error -100
+```
+
+Cloudflare DoH comparison showed `chatgpt.com` should resolve to Cloudflare-like IPs such as:
+
+```text
+chatgpt.com -> 104.18.32.47, 172.64.155.209
+```
+
+## Diagnostic commands
+
+```bash
+python3 - <<'PY'
+import socket
+for h in ['chatgpt.com','accounts.openai.com','auth.openai.com','openai.com']:
+    try:
+        print(h, sorted({x[4][0] for x in socket.getaddrinfo(h,443,proto=socket.IPPROTO_TCP)}))
+    except Exception as e:
+        print(h, 'ERR', e)
+PY
+
+curl -I -L --max-time 12 https://chatgpt.com/ 2>&1 | sed -n '1,45p'
+curl -I -L --max-time 12 https://accounts.openai.com/ 2>&1 | sed -n '1,45p'
+scutil --dns 2>/dev/null | sed -n '1,120p'
+```
+
+## Interpretation
+
+If `openai.com` or `auth.openai.com` returns HTTP/2 403 Cloudflare challenge but `chatgpt.com` / `accounts.openai.com` still fail TLS or resolve to non-Cloudflare/polluted ranges, do **not** continue registration/OAuth automation. Fix PassWall2 DNS handling first.
+
+For BOSS's PassWall2 setup, ensure these domains use proxy-side/remote DNS, not the local ISP resolver:
+
+```text
+chatgpt.com
+accounts.openai.com
+auth.openai.com
+openai.com
+```
+
+macOS resolver in the failing run still had public/ISP DNS entries like `2400:3200::1`, `2402:4e00::`, `114.114.114.114`, and `8.8.8.8`; rules alone were insufficient because DNS was not cleanly hijacked/forwarded for these domains.
+
+## Process hygiene
+
+Old Chrome test processes can continue emitting noisy GCM/Crashpad errors. These are usually not the root cause:
+
+```text
+Failed to connect to MCS endpoint
+ConnectionHandler failed
+Crashpad settings.dat: No such file or directory
+```
+
+Kill stale test Chrome processes after a failed probe so they do not distract from the DNS/TLS issue.
@@ -0,0 +1,86 @@
+# PassWall2 / SOCKS5 Gateway Reachability Probe — 2026-05-08
+
+Session context: after BOSS updated PassWall2 split rules for OpenAI/ChatGPT/Codex OAuth testing, macOS still could not open `chatgpt.com` and Chrome showed `ERR_CONNECTION_CLOSED`.
+
+## Observed commands and results
+
+Low-risk macOS network refresh was performed:
+
+```bash
+dscacheutil -flushcache
+killall -HUP mDNSResponder 2>/dev/null || true
+```
+
+DNS stayed polluted after the cache flush:
+
+```text
+chatgpt.com -> 202.160.128.16 / 2a03:2880:f10e:83:face:b00c:0:25de
+accounts.openai.com -> 192.133.77.189 / 2a03:2880:f117:83:face:b00c:0:25de
+auth.openai.com -> 104.18.41.241 / 172.64.146.15
+openai.com -> 104.18.33.45 / 172.64.154.211
+```
+
+Testing the intended SOCKS5 gateway:
+
+```bash
+nc -vz -w 3 192.168.2.8 1085
+curl --proxy socks5h://192.168.2.8:1085 -I -L --max-time 25 https://chatgpt.com/
+curl --proxy socks5h://192.168.2.8:1085 --max-time 15 https://api.ipify.org
+ping -c 3 -W 1000 192.168.2.8
+arp -n 192.168.2.8
+route -n get 192.168.2.8
+```
+
+Results:
+
+```text
+nc: connectx to 192.168.2.8 port 1085 (tcp) failed: No route to host
+curl: (7) Failed to connect to 192.168.2.8 port 1085: Couldn't connect to server
+ping: sendto: No route to host / 100% packet loss
+arp: 192.168.2.8 had a MAC entry on en0
+route: interface en0, host route present
+```
+
+Browser screenshot after refresh still showed:
+
+```text
+无法访问此网站
+chatgpt.com 意外终止了连接。
+ERR_CONNECTION_CLOSED
+```
+
+## Reusable lesson
+
+For Codex/OpenAI onboarding tests, distinguish three layers before touching extension automation:
+
+1. **Local DNS pollution** — `chatgpt.com` / `accounts.openai.com` resolving to suspicious non-Cloudflare/Facebook-like ranges means domain rules alone are not enough.
+2. **Proxy gateway reachability** — even `socks5h://...` cannot help if the Mac cannot reach the gateway/port. Test `nc`, `curl --proxy socks5h://`, `ping`, `arp`, and `route`.
+3. **Browser page result** — only after gateway and DNS/proxy are healthy should Chrome/extension/OAuth be tested.
+
+Use `socks5h://` rather than `socks5://` in curl probes when the goal is to force DNS resolution through the SOCKS proxy. If `socks5h` fails to connect to the proxy itself, stop and report gateway/port reachability first.
+
+## Suggested probe block
+
+```bash
+PROXY='socks5h://192.168.2.8:1085'
+
+printf '== DNS ==\n'
+python3 - <<'PY'
+import socket
+for h in ['chatgpt.com','accounts.openai.com','auth.openai.com','openai.com']:
+    try:
+        print(h, sorted({x[4][0] for x in socket.getaddrinfo(h,443,proto=socket.IPPROTO_TCP)}))
+    except Exception as e:
+        print(h, 'ERR', e)
+PY
+
+printf '\n== gateway/port ==\n'
+route -n get 192.168.2.8 2>/dev/null || true
+arp -n 192.168.2.8 || true
+ping -c 3 -W 1000 192.168.2.8 || true
+nc -vz -w 3 192.168.2.8 1085 || true
+
+printf '\n== through socks5h ==\n'
+curl --proxy "$PROXY" -I -L --max-time 25 https://chatgpt.com/ 2>&1 | sed -n '1,80p'
+curl --proxy "$PROXY" --max-time 15 https://api.ipify.org 2>&1 || true
+```