Product brief: Multi-Mailbox Ops

1. Problem

The primary user manages several Gmail addresses with distinct personal and business identities. Gmail on iOS makes account switching fluid, but AI assistance is typically bound to one connected mailbox or requires working inside each Gmail session. That prevents simple, reliable requests such as:

• find a thread in a named personal or business mailbox;
• draft a reply from the correct identity without sending it;
• assess and clean a large historical inbox backlog;
• unsubscribe from recurring junk while protecting important mail.

Forwarding everything to one hub improves discovery but does not safely reproduce source-mailbox state, sender identity, draft ownership, archive state, or unsubscribe authority. Direct multi-account operations are the missing layer.

2. Primary user and jobs

Primary user

A single owner-operator who uses Codex as an execution hub across personal and business work and wants mailbox maintenance to feel like scoped repository maintenance.

Jobs to be done

• “Search the mailbox I named and summarize the matching thread.”
• “Draft a reply in that same mailbox, from that identity, and leave it for me to review.”
• “Show me what is occupying this inbox and propose a safe cleanup.”
• “After I approve the exact plan, archive, label, or trash the approved messages and show me what changed.”
• “Unsubscribe me from approved recurring senders and verify the outcome.”

3. Product shape

Multi-Mailbox Ops uses three deliberately separate layers:

1. Standard Gmail proof layer. Proves the conversational workflow and current connector capabilities on one account whose live identity is checked before use.
2. Optional hub convenience layer. Consolidates copies for broad discovery and historical reference. It is optional and non-authoritative.
3. Custom multi-account gateway. Maintains a registry of named mailbox aliases, holds per-account authorization outside the repo, and routes all authoritative operations to the selected source mailbox.

The gateway is the durable product. The standard connector reduces early uncertainty, and the hub may reduce search friction, but neither substitutes for source-account operations.

4. V1 scope

In scope

• Explicit mailbox registry with user-friendly aliases such as personal and ml89.llc.
• Live account-identity and authorization-state checks.
• Search and thread/message retrieval within one explicitly selected mailbox.
• Draft creation and draft revision in the selected source mailbox.
• No send capability exposed anywhere in the V1 gateway.
• Read-only backlog inventory, sender/category clustering, and cleanup-plan preview.
• Approved, bounded label, archive, and recoverable Trash operations.
• Frozen cleanup manifests, pre-execution revalidation, post-execution verification, and rollback receipts.
• A separate unsubscribe workflow with explicit sender-level approval and verification.
• Synthetic and isolated-account testing before production mailbox mutation.
• Audit records containing metadata and opaque IDs, not raw mail bodies or secrets.

Out of scope for V1

• Sending, scheduling, or auto-replying to email.
• Autonomous inbox mutation without an approved, bounded plan.
• Permanent deletion or emptying Trash/Spam.
• Treating a hub copy as proof of source-mailbox state.
• Shared-team delegation, broad enterprise administration, or third-party mailbox providers.
• Training models on mailbox content or committing mailbox data to the repository.
• Background cleanup that silently expands beyond a user-approved snapshot.

5. Safety posture

V1 safety is capability-based. The send function is not merely disabled by a prompt; it is absent from the tool surface. Cleanup requires a preview and explicit approval of scope. At execution time, the gateway revalidates account identity, message state, age, protection rules, and plan freshness. A mismatch skips the item or invalidates the plan rather than guessing.

Unsubscribe is allowed only through its dedicated workflow because it creates an external side effect. Each action is approved per sender or bounded batch, and unsubscribe-by-email cannot bypass the no-send invariant.

6. Desired outcomes and metrics

Activation

• Every configured mailbox passes an identity test without alias ambiguity.
• A user can search a named mailbox and create a correctly addressed draft in that same mailbox.
• A synthetic or isolated inbox cleanup completes through preview, approval, execution, verification, and rollback.

Safety

• Zero sent messages from the V1 gateway.
• Zero mutations against an unselected or misidentified mailbox.
• Zero permanent deletions.
• One hundred percent of cleanup mutations trace to an approved manifest and produce a receipt.
• One hundred percent of stale or materially changed plans fail closed or skip affected items.

Utility

• Named-mailbox search succeeds without manual Gmail account switching.
• Cleanup reports distinguish reviewed, approved, changed, skipped, failed, and rolled-back counts.
• Inbox count can be reduced materially without losing protected messages or conversational context.

7. Key risks and validation

Assumption	Risk if false	Validation
Gmail OAuth can be authorized separately for every required account.	The gateway cannot offer reliable multi-account coverage.	Complete an account-by-account permission audit before production implementation.
A draft-only gateway can be enforced structurally even though Google's minimum Gmail scope is shared with send.	A coding, endpoint, or tool-selection error could send mail.	Omit send methods/routes, positively allow only approved endpoints, attest the shared scope, and add contract tests that reject any send capability.
Reversible cleanup is sufficient for meaningful Inbox Zero progress.	Backlog remains too large or noisy.	Measure inbox reduction by action class in an isolated pilot.
Source mail can be classified without retaining sensitive content.	Auditability conflicts with privacy.	Use ephemeral processing, metadata-only receipts, and privacy review.
Unsubscribe endpoints are reliable enough to automate selectively.	External requests fail, send mail, or affect the wrong subscription.	Support only verified mechanisms, require separate approval, and report unsupported cases.

8. Open product questions

• Which Gmail accounts and human-friendly aliases belong in the initial registry?
• Which accounts require Google Workspace administrator consent or have special retention rules?
• Should the optional hub receive all mail, only selected accounts, or remain deferred until the gateway is proven?
• What sender classes may be archived by default after approval, and which must always be protected?
• What maximum plan age and batch size should V1 enforce for production cleanup?