# ClawEmail external-receive gate for OpenAI verification (2026-05-10)

Context: during a fresh Codex2API/OpenAI OAuth registration run with `socks5://192.168.2.8:1085`, a new ClawEmail sub-mailbox was created successfully:

```text
chickliu.<8letters>@claw.163.com
```

The OpenAI flow reached `https://auth.openai.com/email-verification` after password creation, but no OpenAI verification email arrived. `mail-cli clawemail info --uid ... --json` showed the newly-created sub-mailbox defaults to:

```json
{
  "commLevel": 1,
  "extReceiveType": 0,
  "extSendType": 0
}
```

Meaning: internal communication only. External OpenAI mail is blocked unless communication settings are changed.

## Required gate before submitting a new sub-mailbox to OpenAI

After creating a per-run ClawEmail sub-mailbox and before using it in OpenAI registration:

1. Verify mailbox info:

```bash
mail-cli clawemail info --uid "$NEW_UID" --json
```

2. If it is not already external-receive enabled, stop and set it in ClawEmail Dashboard:

```text
通讯规则 -> 开放外部通信 -> 收信范围：所有人
```

Target state:

```json
{
  "commLevel": 2,
  "extReceiveType": 1
}
```

3. Only after the gate passes, submit the mailbox to OpenAI / click resend verification.

## Why this matters

If the sub-mailbox remains `commLevel=1`, OpenAI verification mail may never arrive. Repeated resend attempts can also destabilize the OpenAI email-verification page (observed page class: HTTP 500 / `chrome-error://chromewebdata/`) and wastes a registration session.

## mail-cli profile pitfall after cleanup

If old test sub-mailboxes were deleted, named profiles such as `codex-current`, `codex-retry`, or `codex-zlajiqjc` can still point to deleted mailboxes. Polling with a stale profile can return errors like:

```text
JWT_FETCH_FAILED / 资源不存在
```

For new runs, either:

- update/create a profile for the new mailbox before polling, or
- poll through the verified default/master profile only if the API actually exposes the new sub-mailbox's mail there.

Do not treat `JWT_FETCH_FAILED` from a stale profile as an OpenAI non-delivery signal.

## Recommended automation behavior

The low-token runner should include a `clawemail_external_receive_gate` phase:

```json
{"phase":"clawemail_external_receive_gate","uid":"chickliu.<prefix>@claw.163.com","commLevel":1,"extReceiveType":0,"result":"blocked_requires_dashboard"}
```

When blocked, emit a screenshot/instruction and stop before burning the OpenAI auth session or proceeding to 5sim.