Files
codex-oauth-plus-onboarding…/skill/codex-oauth-plus-onboarding/references/clawemail-external-receive-gate-openai-2026-05-10.md
T

2.5 KiB

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:

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:

{
  "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:
mail-cli clawemail info --uid "$NEW_UID" --json
  1. If it is not already external-receive enabled, stop and set it in ClawEmail Dashboard:
通讯规则 -> 开放外部通信 -> 收信范围:所有人

Target state:

{
  "commLevel": 2,
  "extReceiveType": 1
}
  1. 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:

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.

The low-token runner should include a clawemail_external_receive_gate phase:

{"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.