# ClawEmail Prefix Probe Notes — 2026-05

Context: During Codex OAuth registration testing for BOSS, we needed fresh ClawEmail sub-mailboxes and discovered live API constraints stricter than public docs.

## Official/public expectation

Docs/help say `mail-cli clawemail create --prefix <prefix> --type sub` accepts 1-64 characters and examples mention `bot1`, `bot.v1`, `my-agent`, `support`.

## Live observed behavior

Using BOSS's primary `chickliu@claw.163.com`, successful sub-mailbox shape is:

```text
chickliu.<prefix>@claw.163.com
```

Probed prefixes were created and immediately deleted when successful.

Accepted examples:

- `a`, `ab`, `abc`, `bot`, `bot1`, `test`, `codex`, `oauth`
- `codexabcdef` (11 chars) accepted
- random lowercase lengths 1-11 accepted
- digit suffix examples like `codex12345` accepted

Rejected examples:

- length 12+ such as `codexabcdefg`, `xxxxxxxxxxxx`
- dot/hyphen examples: `a.b`, `bot.v1`, `my-agent`, `abc.def`

Observed practical rule:

```text
^[A-Za-z0-9]{1,11}$
```

## BOSS preference for Codex/OAuth runs

BOSS corrected the desired mailbox shape: after the dot, use **only 8 lowercase English random letters**, with no `cod`/`codex` fixed prefix.

Example:

```text
chickliu.ktqcxzux@claw.163.com
```

Env policy used locally:

```text
CLAWEMAIL_PREFIX=
CLAWEMAIL_RANDOM_SUFFIX_LENGTH=8
CLAWEMAIL_RANDOM_SUFFIX_CHARSET=abcdefghijklmnopqrstuvwxyz
CLAWEMAIL_PREFIX_WITH_RANDOM_SUFFIX=true
```

When a helper does not support empty base prefix + suffix policy, generate the full 8-letter create prefix yourself and pass it directly:

```bash
mail-cli clawemail create --prefix "$RANDOM_8_LOWERCASE" --type sub --display-name "Codex OAuth $RANDOM_8_LOWERCASE" --json
```

Record every created mailbox in the local JSONL record file with status `pending`, then update to `success`, `failed_*`, or `deleted_replaced`.