fix: keep skill package layout

2026-05-10 08:45:11 +08:00
parent 828a208bde
commit dc7e952c43
17 changed files with 67 additions and 1188 deletions
@@ -47,12 +47,15 @@ These are confirmed operating rules for BOSS's environment:
 - The new account password is unified through `CUSTOM_PASSWORD`. If it is empty, stop and ask BOSS to fill it, unless BOSS explicitly allows auto-generation for that run.
 - ClawEmail creates a fresh mailbox for every run (`CLAWEMAIL_CREATE_PER_RUN=true`). Record every created mailbox locally with outcome classification: pending, success, failed.
 - Phone/SMS platform has no default. Keep `PHONE_VERIFICATION_ENABLED=false` and `PHONE_SMS_PROVIDER` empty unless BOSS configures one or approves enabling it after a phone verification appears.
+- If phone verification appears and BOSS has configured 5sim, use **SMS activation for `openai`**, not WhatsApp receive channels. The original extension's 5sim provider buys `/v1/user/buy/activation/{country}/{operator}/openai`, polls `/v1/user/check/{activationId}`, and finishes/cancels the activation. Follow the configured `FIVE_SIM_COUNTRY_ID` first; if it is empty, the extension default is `vietnam`. Do **not** silently switch countries after a rejected number unless BOSS changes config or approves fallback. Before buying/submitting a non-USA number, verify the OpenAI visible country selector is already the expected country (for example `越南 (+84)`); if it reverted to `美国 (+1)`, fix the selector first or the number will be parsed as invalid. Use visible UI paste/click on `add-phone` when possible because CDP-only input mutation can desync React state and revert the country on submit. If a number is **not immediately rejected**, do not cancel it after one polling timeout: poll 5sim, click OpenAI `重新发送`, poll again, and retry resend at least once before canceling/rotating. If changing proxy (for example `1085` → `1083`), expect OpenAI auth session invalidation and restart from a fresh target OAuth URL. Codex2API env URLs may point at `/admin/accounts`; derive the API origin before calling `/api/admin/oauth/generate-auth-url`. See `references/openai-add-phone-5sim-sms-activation-2026-05-10.md`, `references/openai-phone-verification-5sim-sms-2026-05-10.md`, and `references/openai-phone-verification-proxy1083-resend-2026-05-10.md` for observed behavior, resend strategy, proxy-switch recovery, and pitfalls.
 - Plus mode uses `PLUS_PAYMENT_METHOD=gopay`. Any paid GoPay action still requires explicit confirmation immediately before payment/approval.
 - GoPay WhatsApp OTP uses **方案 A / manual checkpoint**: set `GOPAY_OTP_SOURCE=manual`. The extension detects OTP input and opens a side-panel prompt (`requestGoPayOtpInput` / “输入 GoPay 验证码”); BOSS pastes the WhatsApp code, then the extension fills OTP, fills `GOPAY_PIN`, and continues.
 - `GOPAY_OTP` should normally stay empty before the run. It is only a temporary prefill/cache for the current OTP dialog, not a durable secret.
 - Do not implement WhatsApp scraping/API automation unless BOSS explicitly requests it later.

-
+- When BOSS says the environment is normal and asks to start registration testing, treat `socks5://192.168.2.8:1085` as the expected browser proxy unless BOSS overrides it. If `BROWSER_PROXY_SERVER` is empty, patch the local env to this SOCKS5 endpoint and verify it before launching Chrome; do not stop with a question asking whether to use it.
+- For ordinary-account test runs, set `PLUS_MODE_ENABLED=false` before launching. Keep `PLUS_PAYMENT_METHOD=gopay` untouched for later Plus runs, but do not enter Plus/payment steps.
+- Registration/OAuth tests are step-gated for BOSS: after environment/config prep and mailbox creation, report the created mailbox and wait for explicit “继续” before launching the visible browser flow.

 1. **Explicit target**: BOSS must specify exactly one target mode: `sub2api`, `codex2api`, or `cpa`; there is no default target, and an empty `PANEL_MODE` must stop execution.
 2. **Single-run default**: default to one account / one OAuth flow unless BOSS explicitly requests a count.
@@ -258,6 +261,8 @@ Important permissions include `tabs`, `webNavigation`, `webRequest`, `proxy`, `d

 ## Normal OAuth Flow Steps

+**BOSS correction / manual-flow allowance:** if BOSS asks only to test whether ordinary registration works, do not over-focus on running the original extension as the automation engine. It is acceptable to follow the extension's normal-flow sequence manually through visible Chrome, CDP, and `mail-cli`. The extension should be treated as a process reference unless BOSS explicitly asks to use it. Still keep all checkpoints: stop for CAPTCHA/Cloudflare/security challenge/phone/payment, and do not proceed to OAuth until email verification succeeds.
+
 Normal mode step definitions:

 1. `open-chatgpt` — clear ChatGPT/OpenAI cookies and open ChatGPT.
@@ -371,12 +376,9 @@ The built-in export function exports `getPersistedSettings()` as JSON; this can

 ## Troubleshooting

-### Extension does not appear
+### Google Chrome stable may ignore `--load-extension`

- Confirm Chrome was launched with `--load-extension` and `--disable-extensions-except` pointing to the repo directory.
- Confirm `manifest.json` exists and is Manifest V3.
- Use a non-headless browser. Chrome extension side panels are usually not practical in headless mode.
- When using Chrome DevTools Protocol, do not assume the first `/json` `service_worker` target is this automation extension; verify the extension is visible in `chrome://extensions/` and that the target URL/ID corresponds to the unpacked repo before sending `SAVE_SETTING` / `AUTO_RUN`.
+On BOSS's macOS Chrome stable 147, verbose logs showed `--load-extension is not allowed in Google Chrome, ignoring.` In that case, `ps` still shows the flag but the extension card never appears. Do not keep relaunching the same way. Use the visible UI workaround: open `chrome://extensions`, enable Developer Mode, physically click **加载未打包的扩展程序**, choose the repo folder in the macOS picker, then verify the unpacked card is `ENABLED`. See `references/chrome-147-unpacked-extension-loading-2026-05-09.md`.

 ### PassWall2/DNS split rules still polluted

@@ -406,9 +408,31 @@ curl --proxy socks5h://192.168.2.8:1085 -I -L --max-time 30 https://chatgpt.com/

 Use `socks5h://` with `curl` so DNS resolution happens through the SOCKS proxy. If proxy TCP tests fail with `No route to host`, stop: this is a LAN/gateway/proxy reachability problem, not an OpenAI OAuth or extension problem.

-### SOCKS5 gateway not reachable
+### OpenAI/ChatGPT direct-connect preflight before launching Chrome
+
+Before opening the visible Chrome registration flow, run a raw DNS/TLS preflight even if the rest of the environment looks healthy:
+
+```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
+curl -I -L --max-time 25 https://chatgpt.com/ | sed -n '1,30p'
+```
+
+If `BROWSER_PROXY_SERVER` is empty and DNS/TLS shows known pollution or transport failure, **stop before launching the registration/OAuth flow**. Examples observed during BOSS's Codex2API + GoPay plan-A test:
+
+- `chatgpt.com` resolving to non-Cloudflare/suspicious ranges such as `67.230.169.182` or odd IPv6 entries.
+- `accounts.openai.com` resolving to suspicious ranges such as `199.59.149.234` / `2001::...`.
+- `curl https://chatgpt.com/` failing with `LibreSSL SSL_connect: SSL_ERROR_SYSCALL`.
+
+Treat this as an environment/proxy/DNS problem, not an extension, ClawEmail, Codex2API, or account problem. Ask BOSS to fill a reachable `BROWSER_PROXY_SERVER=socks5://host:port` or `http://host:port`, then re-run proxy TCP/exit-IP/ChatGPT checks before starting Chrome. This avoids burning a registration attempt on a flow that will almost certainly stall on OpenAI auth.
+

-If BOSS asks to test a specific proxy such as `socks5://192.168.2.8:1085`, test gateway reachability before browser/extension automation. Use `socks5h://` in curl when the intent is to force DNS through the SOCKS proxy:

 ```bash
 PROXY='socks5h://192.168.2.8:1085'
@@ -422,6 +446,31 @@ ping -c 3 -W 1000 192.168.2.8 || true

 If the Mac cannot reach the gateway/port (`No route to host`, `Couldn't connect to server`, ping loss), report this as a local gateway/port problem rather than continuing OAuth or extension tests. See `references/passwall2-socks5-gateway-reachability-2026-05-08.md` for the session example.

+### Extension launch appears successful but `chrome://extensions` is empty
+
+Chrome/CDP can mislead in multi-profile sessions. A process may show `--load-extension`, and CDP may even transiently show a `chrome-extension://.../service_worker.js` target, while the intended unpacked extension is not actually visible or registered in the isolated profile.
+
+Before starting OpenAI registration, verify the intended automation extension with stronger evidence:
+
+- `chrome://extensions/` visibly shows the `codex-oauth-automation-extension` unpacked card; or
+- `Default/Preferences` has an `extensions.settings` entry whose manifest/path match the intended repo; or
+- the intended extension page/sidepanel opens and renders expected UI; or
+- an extension-context runtime call reads the expected manifest/state.
+
+If `chrome://extensions` is empty and `extensions.settings` is empty, stop before registration. Report the block as **extension launch/registration failure before signup**, keep the ClawEmail record pending/failed according to whether signup was actually attempted, and avoid burning the mailbox on a manual unsupported flow. See `references/chrome-147-unpacked-extension-loading-2026-05-09.md` for the observed Chrome 147 anomaly and debug checklist.
+
+### OpenAI verification email does not arrive in ClawEmail
+
+A 2026-05-09 ordinary-registration test reached OpenAI's normal `email-verification` page with two fresh ClawEmail sub-mailboxes, but no OpenAI code arrived in inbox or spam even after resend. Both sub-mailboxes passed a self-send receive test, so the block was classified as OpenAI/ClawEmail deliverability rather than browser, proxy, extension, CAPTCHA, or phone-verification failure. See `references/openai-clawemail-verification-nondelivery-2026-05-09.md`.
+
+When this happens:
+
+1. Confirm the exact email in the OpenAI page body via DOM, not OCR only.
+2. Poll the **sub-mailbox profile**, not just the default primary mailbox profile.
+3. Check inbox and spam.
+4. Send a self-test email to the sub-mailbox and verify it arrives.
+5. If self-test works but OpenAI mail still does not arrive after resend, stop and record `openai_email_verification` failure; try a primary ClawEmail mailbox or another provider next.
+
 ### Proxy not applied

 - Visit an IP-check page in the isolated browser before starting.
@@ -453,6 +502,16 @@ If the Mac cannot reach the gateway/port (`No route to host`, `Couldn't connect
 - Confirm GPC helper URL/card key/phone/PIN/OTP channel settings.
 - Stop before retrying paid operations repeatedly; ask BOSS.

+See `references/macos-screenshot-proxy-and-registration-prep-2026-05-09.md` for the session note covering the macOS TCC screenshot fix, LAN/SOCKS5 verification, and ordinary-registration prep sequence.
+
+See `references/openai-clawemail-verification-nondelivery-2026-05-09.md` for the ordinary registration test where OpenAI reached the email-verification page for two ClawEmail submailboxes, but no OpenAI verification email arrived despite submailbox self-test delivery working.
+
+See `references/openai-add-phone-5sim-sms-activation-2026-05-10.md` for the phone-verification continuation where OpenAI `add-phone` required SMS, BOSS corrected that WhatsApp receive channels must not be used, and 5sim `activation/*/openai` orders plus visible country selection were identified as the right class of workflow.
+
+See `references/openai-phone-verification-5sim-sms-2026-05-10.md` for the later detailed retry notes: follow configured country/default `vietnam`, cancel failed 5sim orders before buying new ones, treat OpenAI `无法向此电话号码发送验证码` as a number/provider rejection, and avoid CDP-only mutations that desync the React country selector back to `美国 (+1)`.
+
+See `references/openai-add-phone-1083-vietnam-resend-2026-05-10.md` for the follow-up test requested by BOSS: switch browser proxy to `socks5://192.168.2.8:1083`, regenerate Codex2API OAuth URL from the origin API when the auth session expires, continue with configured-country `vietnam` SMS activation, and for non-rejected numbers poll 5sim then click `重新发送` before canceling/retrying.
+
 ## Verification Checklist

 - [ ] Config file exists at `~/.hermes/env/codex_oauth_onboarding.env` with mode-specific fields.
@@ -0,0 +1,128 @@
+# Chrome 147 unpacked extension loading anomaly (2026-05-09)
+
+## Context
+
+During a Codex OAuth ordinary-account test run, the flow stopped before registration because the isolated visible Google Chrome profile did not reliably expose the unpacked automation extension.
+
+Environment observed:
+
+- Chrome stable: `Chrome/147.0.7727.139`
+- Browser binary: `/Applications/Google Chrome.app/Contents/MacOS/Google Chrome`
+- Isolated profile root: `/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth`
+- Remote debugging: `127.0.0.1:9223` / test `9224`
+- Automation extension repo: `/Users/chick/.Hermes/workspace/research/codex-oauth-automation-extension`
+- Browser proxy used for the actual run: `socks5://192.168.2.8:1085`
+
+Launch flags used for the working profile included:
+
+```bash
+--user-data-dir=/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth/20260509-192515-working
+--remote-debugging-port=9223
+--enable-extensions
+--disable-extensions-except=/Users/chick/.Hermes/workspace/research/codex-oauth-automation-extension
+--load-extension=/Users/chick/.Hermes/workspace/research/codex-oauth-automation-extension
+--proxy-server=socks5://192.168.2.8:1085
+--no-first-run
+--no-default-browser-check
+--new-window https://api.ipify.org?format=json
+```
+
+## Symptoms
+
+- Chrome process and CDP port started correctly.
+- Process args showed `--load-extension` and `--disable-extensions-except` exactly as expected.
+- CDP `/json/version` worked.
+- CDP `/json` only showed regular pages such as `https://api.ipify.org/?format=json`.
+- Opening `chrome://extensions/` via CDP `PUT /json/new?...` worked, but the page was empty.
+- `Default/Preferences` existed, but `extensions.settings` was `{}` / empty.
+- Visual screenshot confirmed `chrome://extensions` displayed no `codex-oauth-automation-extension` card and no visible extension error.
+- Chrome stderr had updater/GCM/GPU noise but no clear manifest error.
+
+A retry/minimal-extension probe showed confusing behavior:
+
+- A trivial unpacked MV3 extension under `/tmp/hermes-test-extension` was launched with the same style of `--load-extension` flags on port `9224`.
+- CDP at one point listed `service_worker | chrome-extension://fignfifoniblkonapihmkfakmlgkbkcf/service_worker.js`, matching the prior automation extension ID, even when the current test was a different minimal extension.
+- `chrome://extensions/` still displayed no extension cards.
+- `Default/Preferences` `extensions.settings` could still be empty even while transient extension-related targets appeared.
+
+## Confirmed root cause: Google Chrome stable blocks the flag
+
+Verbose Chrome logging later produced the decisive line:
+
+```text
+--load-extension is not allowed in Google Chrome, ignoring.
+```
+
+This means that on this BOSS macOS setup, Chrome stable 147 can show the `--load-extension` argument in `ps`, but still intentionally ignore it. This affected both the real automation extension and a minimal MV3 test extension, proving it was not a manifest/repo problem.
+
+### Working workaround: visible UI load-unpacked
+
+Use the real visible Chrome UI instead of the command-line flag:
+
+1. Launch the isolated proxied Chrome profile **without relying on** `--load-extension`:
+
+```bash
+/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
+  --user-data-dir="$PROFILE_DIR" \
+  --remote-debugging-port=9223 \
+  --proxy-server="$BROWSER_PROXY_SERVER" \
+  --no-first-run \
+  --no-default-browser-check \
+  --new-window chrome://extensions/
+```
+
+2. Open `chrome://extensions/` via visible UI or CDP `PUT /json/new?chrome%3A%2F%2Fextensions%2F` if Chrome landed on a new-tab page.
+3. Enable Developer Mode. CDP from the `chrome://extensions` page can do this:
+
+```js
+chrome.developerPrivate.updateProfileConfiguration({ inDeveloperMode: true })
+```
+
+4. Physically click **加载未打包的扩展程序** in the visible Chrome window. A DOM `btn.click()` may not open the native file picker; `cliclick` physical coordinates did.
+5. In the macOS “选择扩展程序目录” dialog, use `Cmd+Shift+G`, paste the extension repo path, press Enter, then press Enter/选择.
+6. Verify `chrome://extensions` shows the card:
+   - name `codex-oauth-automation-extension`
+   - location `UNPACKED`
+   - state `ENABLED`
+   - service worker `chrome-extension://<id>/background.js`
+   - no manifest/runtime errors
+
+Observed successful extension ID for the 2026-05-09 run: `inebnmemmodcfoejiofegbeckbmjdlil`.
+
+## Suggested next debug steps
+
+1. Confirm no old profile owns the CDP port:
+
+```bash
+lsof -nP -iTCP:9223 -sTCP:LISTEN || true
+ps auxww | grep -F '/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth/' | grep -v grep || true
+```
+
+2. Kill only exact isolated profile processes; do not kill BOSS's normal Chrome unless explicitly approved.
+
+```bash
+pkill -f '/Users/chick/.Hermes/workspace/browser-profiles/codex-oauth/<profile-name>' || true
+```
+
+3. Launch a clean profile and verify with all three channels: CDP targets, Preferences, and screenshot of `chrome://extensions/`.
+
+4. If Chrome stable continues hiding/ignoring unpacked extensions, check for policy restrictions and extension developer-mode behavior:
+
+```bash
+chrome://policy
+# or inspect policy files / managed preferences if present
+```
+
+5. Consider a controlled comparison with another local Chrome/Chromium build only after preserving the requirement that the registration itself runs in a real visible browser and with the intended proxy.
+
+## User-facing reporting guidance
+
+When this happens, report clearly that the run is blocked **before registration**, not on OpenAI signup itself. Include:
+
+- browser/profile launched: yes/no
+- proxy applied: yes/no
+- extension visible/registered: yes/no
+- registration started: no
+- mailbox status remains pending unless a signup was actually attempted
+
+Avoid overclaiming that the extension loaded based only on a sleeping/transient service worker target.
@@ -0,0 +1,66 @@
+# 2026-05-09 macOS screenshot and registration-test notes
+
+## Visible-window screenshot fix
+
+During a Screen Sharing / screenshot debugging session, `screencapture` initially produced valid PNG files that contained only wallpaper and the menu bar even though Chrome was frontmost. `stat -f '%Su' /dev/console` returned `root`, but `scutil <<< 'show State:/Users/ConsoleUser'` showed the real GUI session was `chick` and on-console.
+
+Useful diagnostic sequence:
+
+```bash
+stat -f '%Su' /dev/console 2>/dev/null || true
+scutil <<< 'show State:/Users/ConsoleUser' 2>/dev/null | sed -n '1,40p' || true
+osascript -e 'tell application "System Events" to get name of first application process whose frontmost is true' 2>&1 || true
+osascript -e 'tell application "System Events" to get name of every application process whose visible is true' 2>&1 || true
+log show --last 5m --style compact \
+  --predicate 'process == "tccd" AND (eventMessage CONTAINS[c] "Accessibility" OR eventMessage CONTAINS[c] "ScreenCapture" OR eventMessage CONTAINS[c] "osascript" OR eventMessage CONTAINS[c] "python")' \
+  2>/dev/null | tail -120
+```
+
+Key log signal: TCC attributed denied Accessibility/ScreenCapture requests to Hermes gateway's responsible Homebrew Python, not just Terminal or osascript:
+
+```text
+/Users/chick/homebrew/Cellar/python@3.11/3.11.15/Frameworks/Python.framework/Versions/3.11/bin/python3.11
+/Users/chick/homebrew/Cellar/python@3.11/3.11.15/Frameworks/Python.framework/Versions/3.11/Resources/Python.app
+```
+
+Grant **Accessibility** and **Screen Recording / 录屏与系统录音** to those paths. After grant, validation showed:
+
+```text
+System Settings
+Terminal windows=0
+Finder windows=0
+Google Chrome windows=1
+System Settings windows=1
+```
+
+A full `screencapture` then included Chrome, System Settings, Dock, menu bar, and notifications. A cropped window capture using AppleScript bounds also worked.
+
+## LAN and SOCKS5 checks before registration
+
+After Screen Sharing reset and permissions fix, these checks passed:
+
+- `192.168.2.1`: ping OK; ports 80/443 open; visible Chrome loaded iKuai login page at `192.168.2.1/login#/login`.
+- `socks5://192.168.2.8:1085`: ping/TCP OK; `curl -x socks5h://192.168.2.8:1085 https://www.google.com/generate_204` returned HTTP 204; proxy exit IP was `54.65.165.232`.
+
+For BOSS's Codex OAuth registration tests, if the env proxy field is empty after this check, set:
+
+```bash
+BROWSER_PROXY_SERVER=socks5://192.168.2.8:1085
+```
+
+Then verify with:
+
+```bash
+curl -x socks5h://192.168.2.8:1085 -sS --connect-timeout 8 --max-time 15 https://api.ipify.org
+```
+
+## Ordinary registration test setup
+
+When BOSS asked to skip Plus and register a normal account:
+
+- Set `PLUS_MODE_ENABLED=false`.
+- Keep target `PANEL_MODE=codex2api`.
+- Verify target `http://192.168.2.62:7878/admin/accounts` returned HTTP 200.
+- Create ClawEmail sub-mailbox using exactly 8 lowercase letters, e.g. `chickliu.zlajiqjc@claw.163.com`.
+- Append a `pending` record to `/Users/chick/.Hermes/workspace/codex-oauth/run-records/clawemail_accounts.jsonl`.
+- Stop and wait for BOSS to say “继续” before launching the visible browser flow.
@@ -0,0 +1,67 @@
+# OpenAI add-phone: 1083 proxy + 5sim Vietnam SMS retry/resend notes (2026-05-10)
+
+Context: during Codex2API OAuth for a freshly registered ClawEmail-backed ChatGPT account, OpenAI required `add-phone`. BOSS suggested switching browser proxy from `socks5://192.168.2.8:1085` to `socks5://192.168.2.8:1083` because phone rejection might be proxy-node related.
+
+## Proxy switch observations
+
+- Updated local env `BROWSER_PROXY_SERVER=socks5://192.168.2.8:1083`.
+- `1083` TCP was reachable and `curl --proxy socks5h://192.168.2.8:1083 https://api.ipify.org` showed exit IP `43.207.194.18`.
+- `curl` to ChatGPT via `1083` returned Cloudflare `HTTP 403` with `cf-mitigated: challenge`, but visible Chrome did not show a challenge during the tested OAuth flow.
+- Restarting the isolated Chrome profile with `1083` invalidated the OpenAI auth session (`你的会话已结束`). Re-open the Codex2API OAuth URL and repeat email login rather than trying to continue the old `add-phone` URL.
+- If `CODEX2API_URL` points at an admin page such as `/admin/accounts`, strip it to origin before API calls. Correct URL pattern observed:
+  - `POST http://192.168.2.62:7878/api/admin/oauth/generate-auth-url`
+  - header: `X-Admin-Key: [REDACTED]`
+  - returns `auth_url` and `session_id`.
+
+## Email re-login after proxy switch
+
+After reopening OAuth under `1083`, OpenAI showed `auth.openai.com/log-in`. Submit the current ClawEmail sub-mailbox, poll `mail-cli --profile codex-current mail list --fid 1 --limit 30 --json`, choose the newest OpenAI code by date (not list order), and fill it. This returned to `https://auth.openai.com/add-phone`.
+
+## 5sim country/provider rules confirmed
+
+- Use SMS activation, not WhatsApp:
+  - `/v1/user/buy/activation/{country}/{operator}/openai`
+  - `/v1/user/check/{activationId}`
+- Follow configured `FIVE_SIM_COUNTRY_ID` first. If empty, original extension default is `vietnam`.
+- Current config had `FIVE_SIM_COUNTRY_ID=` empty, so all retries used `vietnam` with `operator=any`.
+- Before every purchase/submission, verify OpenAI country selector is visibly `越南 (+84)`. If it is `美国 (+1)`, select Vietnam through the visible dropdown first. CDP-only input/country mutations can desync React state and cause invalid parsing.
+
+## Retry policy learned
+
+Use two distinct branches:
+
+1. If OpenAI returns `无法向此电话号码发送验证码。请稍后重试或使用其他号码。` immediately:
+   - Treat as provider/number rejection.
+   - Cancel the 5sim activation.
+   - Buy a new number in the configured country.
+2. If the number is not immediately rejected:
+   - Keep the activation.
+   - Poll 5sim for SMS.
+   - If no SMS arrives, try page `重新发送` before canceling.
+   - Poll again after resend. BOSS explicitly requested using resend for non-rejected numbers.
+
+Observed on `1083` + Vietnam:
+
+- Multiple Vietnam numbers were directly rejected.
+- Some numbers were not immediately rejected, but no SMS arrived in 5sim after repeated polling and attempted resend.
+- After canceling a non-rejected activation, OpenAI may navigate/settle to `电子邮件地址已验证` at `auth.openai.com/email-verification`. To continue, re-open the current Codex2API OAuth URL and repeat email login to get back to `add-phone`.
+
+## Practical implementation notes
+
+- Cancel any active/rejected 5sim order before buying the next number to avoid cost leakage.
+- Use visible Chrome/UI clicks for country selection and phone submission; do not rely solely on DOM mutation.
+- Button coordinates from the tested macOS/Chrome layout:
+  - country dropdown around `(622,496)`
+  - phone input around `(622,561)`
+  - continue button around `(622,636)`
+  - Vietnam row after paging down around `(620,1173)`
+- After direct submit, inspect page text for:
+  - direct rejection string: `无法向此电话号码发送验证码`
+  - invalid country/number parsing: `电话号码无效`
+  - SMS wait/code page or absence of rejection.
+- The previous automation tried 5 configured-country numbers before resend logic and then additional numbers with resend logic. Vietnam pool remained unreliable.
+
+## Safety / reporting
+
+- Redact phone numbers, 5sim API key, Codex2API admin key, OAuth callback URL/code, and account password.
+- It is OK to report activation IDs and masked phone prefixes/suffixes if useful for debugging.
@@ -0,0 +1,53 @@
+# OpenAI add-phone with 5sim SMS activation — 2026-05-10
+
+## Context
+During a manual ChatGPT/Codex OAuth onboarding run, ClawEmail verification succeeded and the OpenAI/Codex OAuth flow reached `https://auth.openai.com/add-phone`.
+
+Important correction from BOSS: **phone verification must use SMS activation, not WhatsApp receive channels**.
+
+## Original extension behavior confirmed
+The repo's provider `phone-sms/providers/five-sim.js` uses 5sim **activation** orders:
+
+- Provider: `5sim`
+- Product/service: `openai`
+- Operator: `any` by default
+- Default country: `vietnam`
+- API pattern:
+  - Buy: `/v1/user/buy/activation/{country}/{operator}/openai`
+  - Poll: `/v1/user/check/{activationId}`
+  - Finish: `/v1/user/finish/{activationId}`
+  - Cancel: `/v1/user/cancel/{activationId}`
+  - Ban: `/v1/user/ban/{activationId}`
+- Extract SMS code from latest `sms[].code` or digits in `sms[].text`.
+
+This is a normal SMS OTP workflow, not WhatsApp.
+
+## Observed OpenAI behavior
+OpenAI add-phone page may reject some 5sim SMS numbers immediately after submission:
+
+- Vietnam `+84` 5sim `openai` activation: OpenAI displayed `无法向此电话号码发送验证码。请稍后重试或使用其他号码。`
+- USA `+1` 5sim `openai` activation: same rejection.
+- Indonesia `+62` activation: DOM-level country selection was reverted by the page back to USA, so the number was parsed as `+1` and became invalid.
+
+## Automation pitfall
+The OpenAI country selector on `add-phone` can appear as a `select`, but setting it via JS/CDP may be reverted by the app state. For non-default countries, prefer **visible UI automation** (click dropdown/search/select country) rather than just `select.value=...`.
+
+If the page defaults to USA `+1`, using a USA activation avoids country-selector mismatch, but OpenAI may still reject the virtual number.
+
+## Recommended retry strategy
+1. Follow the configured 5sim country first. If `FIVE_SIM_COUNTRY_ID` is empty, the original extension default is `vietnam`; do **not** silently switch countries just because some numbers are rejected.
+2. Before buying or submitting another non-USA number, stabilize and verify the OpenAI page country selector first. Use visible UI automation to select the country and then confirm via CDP that the visible country button is the expected country (for example `越南 (+84)`). If the page has reverted to `美国 (+1)`, do not buy/submit a Vietnam number; fix the selector first to avoid wasting activations.
+3. Submit the local number without the country code only after the page country is verified.
+4. If OpenAI rejects the number before SMS is sent (`无法向此电话号码发送验证码` / invalid phone), cancel the activation immediately via `/v1/user/cancel/{activationId}` and retry with a **new number in the same configured country**.
+5. Only switch countries when BOSS changes the config or explicitly approves a fallback-country attempt. Good fallback candidates from the original extension support matrix are `england`, `japan`, `germany`, and `thailand`; avoid changing to these automatically.
+6. Once OpenAI accepts and sends SMS, poll `/v1/user/check/{activationId}` until a 4–8 digit code appears.
+7. After successful verification, call `/v1/user/finish/{activationId}`.
+8. If timeout or wrong/rejected number, call `/v1/user/cancel/{activationId}` and continue according to the same configured-country policy.
+
+## Session-specific pitfalls observed later
+- A batch retry script accidentally bought and submitted another Vietnam number after the page country had reverted to USA. The result was `电话号码无效` because the Vietnam number was parsed as `+1`, not because the Vietnam number had been genuinely tested. Future retries must check `country == expected` immediately before buying/submitting.
+- CDP `Runtime.evaluate` may time out after clicking submit while the page/network is busy; always re-query page state afterward before deciding whether the page advanced, rejected, or simply did not submit.
+- 5sim cancel can return HTTP 400 when the order is already non-cancellable or state changed; treat it as a status to report/check, not as proof a new SMS should be bought immediately.
+
+## Sensitive handling
+Do not print or paste 5sim API keys, full phone numbers, OpenAI OAuth callback codes, Codex2API admin keys, or passwords. Mask phone numbers in logs/replies.
@@ -0,0 +1,103 @@
+# OpenAI 验证码未投递到 ClawEmail 子邮箱（2026-05-09）
+
+## 场景
+
+BOSS 要求不依赖 `codex-oauth-automation-extension` 自动化，只参照其流程手动/CDP 驱动普通 ChatGPT/OpenAI 账号注册，并跳过 Plus/GoPay。
+
+环境：
+
+- 真实可见 Google Chrome stable 147
+- 隔离 profile
+- 代理：`socks5://192.168.2.8:1085`
+- 目标：后续 OAuth 到 Codex2API
+- 邮箱：ClawEmail 子邮箱
+
+## 测试邮箱
+
+第一次：
+
+```text
+chickliu.zlajiqjc@claw.163.com
+```
+
+第二次全新 profile + 全新子邮箱：
+
+```text
+chickliu.gmmpioju@claw.163.com
+```
+
+## 观察结果
+
+两次都能进入 OpenAI 邮箱验证码页，页面显示类似：
+
+```text
+检查你的收件箱
+输入我们刚刚向 <clawemail-submailbox> 发送的验证码
+```
+
+未出现：
+
+- CAPTCHA / Cloudflare
+- 手机号验证
+- Plus / 付款页
+
+但 OpenAI 验证码邮件没有到达 ClawEmail 子邮箱：
+
+- 收件箱为空
+- 垃圾箱为空
+- 点击“重新发送电子邮件”后仍未到达
+- 等待约 2 分钟仍无投递
+
+## 排除项
+
+已确认不是子邮箱基础收信问题：
+
+- 给 `chickliu.zlajiqjc@claw.163.com` 自发测试邮件，能收到。
+- 给 `chickliu.gmmpioju@claw.163.com` 自发测试邮件，能收到。
+
+已确认不是邮箱填错：
+
+- 通过页面 DOM 读取验证码页提示文本，确认显示的邮箱与创建的 ClawEmail 子邮箱一致。
+
+已确认不是只查了主邮箱：
+
+- 为子邮箱创建/使用独立 `mail-cli --profile` 查询。
+- 分别查收件箱和垃圾箱。
+
+## 额外异常
+
+第一次邮箱流程中，OpenAI `/email-verification` 页面曾刷新后返回：
+
+```text
+HTTP ERROR 500
+```
+
+重新提交同一邮箱后验证码页恢复，但邮件仍未投递。
+
+## 结论
+
+普通注册流程可以走到 OpenAI 邮箱验证码页，但 `@claw.163.com` 子邮箱未收到 OpenAI 验证码邮件。当前阻塞不是浏览器、代理、扩展、验证码挑战或手机号验证，而是 OpenAI/Auth 邮件投递到 ClawEmail 子邮箱失败或延迟。
+
+## 下次继续测试建议
+
+1. BOSS 先检查 ClawEmail 邮箱设置/后台投递策略/拦截日志。
+2. 继续前先再次测试子邮箱自发/外部普通邮件可收。
+3. 若仍不收 OpenAI 验证码，尝试：
+   - 直接用 ClawEmail 主邮箱 `chickliu@claw.163.com` 测一次；
+   - 换其他真实邮箱/临时邮箱服务；
+   - 检查 OpenAI/Auth0 是否对 `@claw.163.com` 或其子邮箱形态做投递抑制。
+4. 若继续用子邮箱，务必用 `mail-cli --profile <sub-profile>` 查询对应子邮箱，不要只查默认主邮箱。
+
+## 记录文件
+
+失败记录已追加到：
+
+```text
+/Users/chick/.Hermes/workspace/codex-oauth/run-records/clawemail_accounts.jsonl
+```
+
+失败阶段：
+
+```text
+openai_email_verification
+```
@@ -0,0 +1,52 @@
+# OpenAI phone verification with 5sim SMS activation — 2026-05-10
+
+## Context
+
+During a Codex2API OAuth onboarding run for BOSS, OpenAI registration/login reached `https://auth.openai.com/add-phone` after email verification. BOSS corrected that phone verification must use **SMS** receive channels, not WhatsApp. The original `codex-oauth-automation-extension` provider confirmed the right 5sim API shape:
+
+```text
+GET https://5sim.net/v1/user/buy/activation/{country}/{operator}/openai
+GET https://5sim.net/v1/user/check/{activationId}
+GET https://5sim.net/v1/user/cancel/{activationId}
+GET https://5sim.net/v1/user/finish/{activationId}
+```
+
+Use `product=openai`, `operator=any` unless configured otherwise. If `FIVE_SIM_COUNTRY_ID` is empty, the extension default is `vietnam`.
+
+## Learned workflow
+
+1. Cancel any current 5sim activation before switching proxy, country, or retry strategy.
+2. Follow configured country first; do not silently fall back to other countries unless BOSS approves or config changes.
+3. For non-USA numbers, select the OpenAI country selector with visible UI and verify DOM shows the expected country before buying/submitting a number.
+4. Prefer real UI paste/click for the phone page. CDP-only mutation of `input[type=tel]` can desync React state: the visible country may later revert from `越南 (+84)` to `美国 (+1)` on submit.
+5. If OpenAI returns `无法向此电话号码发送验证码。请稍后重试或使用其他号码。`, classify it as a number/provider rejection. Cancel the activation and buy a new number in the same configured region.
+6. If the page shows `电话号码无效。` after non-USA submission, first verify the country selector did not revert to `美国 (+1)`; this may be a selector-state problem, not a bad number.
+7. When changing browser proxy, expect OpenAI auth session invalidation. Re-open OAuth from the target panel, then redo email login/code before returning to `add-phone`.
+8. Codex2API admin page URL may be stored as `/admin/accounts`; derive API origin from the URL before calling `/api/admin/oauth/generate-auth-url`.
+
+## Observed proxy behavior
+
+- `socks5://192.168.2.8:1085`: OpenAI `add-phone` reached; multiple Vietnam 5sim numbers rejected with `无法向此电话号码发送验证码...`.
+- `socks5://192.168.2.8:1083`: TCP and exit IP worked; raw curl to ChatGPT returned Cloudflare challenge 403, but real Chrome loaded OpenAI login. Session changed to `你的会话已结束`, requiring a fresh Codex2API OAuth URL and email code. A fresh Vietnam 5sim number was still rejected.
+
+## Practical checks
+
+```bash
+# Probe proxy with remote DNS
+nc -vz -w 3 192.168.2.8 1083
+curl --proxy socks5h://192.168.2.8:1083 --max-time 20 https://api.ipify.org
+curl --proxy socks5h://192.168.2.8:1083 -I -L --max-time 30 https://chatgpt.com/ | sed -n '1,30p'
+```
+
+```python
+# Derive Codex2API API origin from env URL that may point at /admin/accounts
+from urllib.parse import urlsplit
+raw = CODEX2API_URL
+u = urlsplit(raw)
+origin = f'{u.scheme}://{u.netloc}' if u.scheme and u.netloc else raw.rstrip('/')
+endpoint = origin + '/api/admin/oauth/generate-auth-url'
+```
+
+## Do not leak
+
+Do not print API keys, 5sim token, phone number, OAuth callback URL/code, account password, or admin key in final reports. Mask phone numbers and IDs if not needed.
@@ -0,0 +1,99 @@
+# OpenAI phone verification with 5sim SMS: proxy switch + resend-on-accepted-number notes (2026-05-10)
+
+## Context
+
+During a Codex2API OAuth onboarding run, OpenAI registration/login reached `https://auth.openai.com/add-phone`. BOSS suspected the previous proxy node influenced SMS delivery and asked to switch the visible Chrome browser proxy from `socks5://192.168.2.8:1085` to `socks5://192.168.2.8:1083`.
+
+Important operating constraints from the run:
+
+- Use visible Google Chrome stable with CDP on `127.0.0.1:9223`.
+- Phone verification must use **5sim SMS activation** for product `openai`, not WhatsApp.
+- Follow configured `FIVE_SIM_COUNTRY_ID`; if empty, use the original extension default `vietnam`.
+- For non-USA numbers, verify the visible OpenAI country selector before buying/submitting the number.
+- Do not leak phone numbers, API keys, OAuth URLs with codes, callback URLs, or admin keys.
+
+## Proxy switch behavior
+
+`1083` probe result in this session:
+
+```text
+nc 192.168.2.8 1083 -> TCP succeeded
+curl --proxy socks5h://192.168.2.8:1083 https://api.ipify.org -> 43.207.194.18
+curl --proxy socks5h://192.168.2.8:1083 -I https://chatgpt.com -> HTTP/2 403, cf-mitigated: challenge
+```
+
+Visible Chrome did not show a Cloudflare challenge, but switching proxy caused the OpenAI auth session to become invalid:
+
+```text
+https://auth.openai.com/add-phone -> title: 你的会话已结束 - OpenAI
+```
+
+Recovery pattern:
+
+1. Cancel any active 5sim order before changing proxy.
+2. Update `BROWSER_PROXY_SERVER` in `~/.hermes/env/codex_oauth_onboarding.env`.
+3. Kill/relaunch only the isolated Chrome process using `--remote-debugging-port=9223 --proxy-server=<new proxy>`.
+4. Regenerate a Codex2API OAuth URL from the **origin**, not from an admin page path:
+   - If `CODEX2API_URL=http://host:port/admin/accounts`, strip to `http://host:port`.
+   - Correct endpoint observed: `POST /api/admin/oauth/generate-auth-url` with `X-Admin-Key`.
+5. Re-open the auth URL in the visible Chrome profile.
+6. Re-login via email and poll ClawEmail for the latest OpenAI code.
+7. Continue to `add-phone`.
+
+Pitfall: using `CODEX2API_URL` directly when it contains `/admin/accounts` leads to wrong paths like `/admin/accounts/api/...` and 404. Always parse origin first.
+
+## Country selector pitfall
+
+OpenAI's country selector is React-controlled. CDP-only mutation of `input[type=tel]` can desync country state or let the selector revert to `美国 (+1)`. Future runs should prefer visible UI selection and paste:
+
+1. Clear phone field.
+2. Open country dropdown.
+3. PageDown/scroll to the configured country.
+4. Click the visible country row (Vietnam observed around screen coordinate `(620,1173)` on a 2560x1600 screenshot, but re-check with screenshot/OCR).
+5. Verify DOM/body text includes the expected visible selector, e.g. `越南 (+84)`.
+6. Buy 5sim activation only after the selector is stable.
+7. Paste the local part of the phone via clipboard/UI, not CDP-only assignment.
+8. Click the actual visible `继续` button; button center may differ by layout, verify screenshot if needed.
+
+## Resend strategy correction from BOSS
+
+BOSS corrected the workflow: when OpenAI does **not** immediately reject a phone number, do **not** cancel it after the first 5sim polling timeout. Treat it as an accepted/pending number:
+
+1. Poll `/v1/user/check/{activationId}` for SMS.
+2. If no SMS arrives, click OpenAI's visible/DOM `重新发送` control.
+3. Poll again.
+4. Repeat at least one more resend/poll cycle before canceling.
+5. Only cancel and rotate when:
+   - OpenAI explicitly says `无法向此电话号码发送验证码`; or
+   - the number remains pending after resend attempts and no SMS arrives.
+
+This matters because in this session some Vietnam numbers were not rejected immediately but never delivered SMS on 5sim. Those should be given resend attempts before cancellation.
+
+## Observed results on 1083 + Vietnam
+
+After switching to `socks5://192.168.2.8:1083`, multiple `vietnam/any/openai` SMS activation attempts were made. Outcomes:
+
+- Several numbers were directly rejected by OpenAI with:
+  ```text
+  无法向此电话号码发送验证码。请稍后重试或使用其他号码。
+  ```
+- Some numbers were not immediately rejected, but repeated 5sim checks returned `RECEIVED` with `sms=[]`.
+- Applying the resend strategy still produced no SMS for the accepted/pending numbers in this run.
+- Therefore, the current evidence points to poor availability/deliverability of the 5sim Vietnam OpenAI pool under both `1085` and `1083`, not a WhatsApp-vs-SMS mistake.
+
+## Minimal reusable script pattern
+
+For future automation, encapsulate this loop:
+
+```text
+cancel active order
+ensure OpenAI add-phone page
+ensure visible country selector == configured country
+buy /v1/user/buy/activation/{country}/{operator}/openai
+paste local phone via UI
+click continue
+if explicit reject: cancel + rotate
+else: poll 5sim; click resend; poll; click resend; poll; then cancel + rotate if still no SMS
+```
+
+Do not hard-code `vietnam` unless `FIVE_SIM_COUNTRY_ID` is empty or BOSS explicitly requests it. If BOSS changes config to `england`, `japan`, etc., use that value and update the visible-country selection accordingly.