106 lines
5.2 KiB
Markdown
106 lines
5.2 KiB
Markdown
# Codex OAuth 1085 full run notes: ClawEmail permission + add-phone SMS/WhatsApp behavior (2026-05-10)
|
|
|
|
## Summary
|
|
|
|
This run used proxy `socks5://192.168.2.8:1085`, a fresh ClawEmail sub-mailbox, and a fresh Codex2API OAuth session. The email-registration part is now reproducible. The run reached OpenAI `https://auth.openai.com/add-phone` successfully.
|
|
|
|
Phone verification did not complete because OpenAI accepted the submitted phone numbers but 5sim SMS activation did not receive any SMS after resend. During some non-US country selections, the OpenAI page text changed to a WhatsApp-specific message, suggesting OpenAI may be trying WhatsApp delivery for those regions rather than SMS.
|
|
|
|
No full phone numbers or secrets are stored here.
|
|
|
|
## Working pieces confirmed
|
|
|
|
1. ClawEmail sub-mailbox can be created after cleaning old sub-mailboxes.
|
|
2. Newly-created ClawEmail sub-mailboxes default to internal-only communication:
|
|
- `commLevel=1`
|
|
- `extReceiveType=0`
|
|
- `extSendType=0`
|
|
3. External OpenAI mail will not arrive until the sub-mailbox communication setting is changed.
|
|
4. A dedicated persistent Dashboard browser should be used for master mailbox login:
|
|
- profile: `/Users/chick/.Hermes/workspace/browser-profiles/clawemail-dashboard-persistent`
|
|
- CDP port: `9224`
|
|
- URL: `https://claw.163.com/projects/dashboard/#/`
|
|
5. The ClawEmail Dashboard API base is not bare `/api/v1`; it is:
|
|
- `https://claw.163.com/mailserv-claw-dashboard`
|
|
6. After Dashboard login, the sub-mailbox permission can be updated through:
|
|
- `GET /api/v1/workspaces`
|
|
- `GET /api/v1/mailboxes?workspaceId=<workspaceId>`
|
|
- `POST /api/v1/mailboxes/comm-settings?id=<mailboxId>`
|
|
- body: `{"commLevel":2,"extReceiveType":1,"extSendType":0}`
|
|
7. Verification command:
|
|
- `mail-cli clawemail info --uid <submailbox> --json`
|
|
- expected: `commLevel=2`, `extReceiveType=1`
|
|
8. Once external receive is enabled, OpenAI email codes arrive at the sub-mailbox. In this run, OpenAI sent both temporary login-code style messages and email-verification codes; reading the full body is more reliable than scanning list previews.
|
|
|
|
## OpenAI add-phone page country selection
|
|
|
|
The country selector is backed by a real hidden/native `select` element with ISO country codes. React Aria click events were unreliable in CDP. The reliable approach was setting the native select directly and dispatching input/change:
|
|
|
|
```js
|
|
const sel = document.querySelector('select');
|
|
sel.focus();
|
|
sel.value = 'AR'; // AR, NL, ID, VN, etc.
|
|
sel.dispatchEvent(new Event('input', {bubbles: true}));
|
|
sel.dispatchEvent(new Event('change', {bubbles: true}));
|
|
await new Promise(r => setTimeout(r, 800));
|
|
```
|
|
|
|
Then verify the visible button text, e.g.:
|
|
|
|
```js
|
|
[...document.querySelectorAll('button')]
|
|
.map(b => b.innerText)
|
|
.find(t => /\(\+\d+\)/.test(t))
|
|
```
|
|
|
|
Expected values observed:
|
|
|
|
- Argentina: `阿根廷 (+54)`
|
|
- Netherlands: `荷兰 (+31)`
|
|
- Indonesia: `印度尼西亚 (+62)`
|
|
|
|
## 5sim country-order run results
|
|
|
|
Configured order:
|
|
|
|
```text
|
|
argentina -> netherlands -> indonesia
|
|
```
|
|
|
|
The run used 5sim SMS activation (`product=openai`, operator `any`), not WhatsApp channels.
|
|
|
|
Results:
|
|
|
|
- Argentina: activation `1006713742`, OpenAI did not direct-reject; 5sim status stayed `RECEIVED`, no SMS after initial polling + resend; order canceled.
|
|
- Netherlands: activation `1006714867`, OpenAI did not direct-reject; 5sim status stayed `RECEIVED`, no SMS after initial polling + resend; order canceled.
|
|
- Indonesia: activation `1006715764`, OpenAI did not direct-reject; 5sim status stayed `RECEIVED`, no SMS after initial polling + resend; order canceled.
|
|
|
|
## Important behavior observed
|
|
|
|
For Argentina, after selecting the country, OpenAI page text changed from generic SMS wording:
|
|
|
|
```text
|
|
我们将向该号码发送一次性验证码以进行验证。
|
|
```
|
|
|
|
to WhatsApp wording:
|
|
|
|
```text
|
|
我们会通过 WhatsApp 向该号码发送一次性验证码进行验证。
|
|
```
|
|
|
|
This likely explains why 5sim SMS activation did not receive codes even though OpenAI did not direct-reject the numbers. Future phone tests should detect page wording before buying SMS numbers:
|
|
|
|
- If page says generic SMS/one-time code, continue 5sim SMS.
|
|
- If page explicitly says WhatsApp, either stop before buying SMS or switch to a WhatsApp-capable provider only if BOSS explicitly approves. BOSS previously said OpenAI/Codex接码必须用 SMS, not WhatsApp.
|
|
|
|
## Automation improvements for next runner
|
|
|
|
1. After creating ClawEmail sub-mailbox, immediately update Dashboard communication settings.
|
|
2. Persist Dashboard master login in profile 9224; never put it in disposable OAuth profile 9223.
|
|
3. Read full OpenAI email body to extract code, not only message list preview.
|
|
4. Use native select `.value = ISO` for country selection.
|
|
5. Before buying 5sim, inspect page text for WhatsApp wording. If WhatsApp wording appears and policy is SMS-only, emit blocker and do not buy.
|
|
6. If OpenAI accepted number and navigates to phone-verification but no SMS arrives, resend once, poll again, cancel order, and log compact JSONL.
|
|
7. Some OpenAI phone-verification transitions produce `chrome-error://chromewebdata/` HTTP 500 after waiting/resend. Recover by generating a fresh Codex2API OAuth session and logging in with the same email/password; the account returns to add-phone.
|