# 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.