Project

    Multi Mailbox Ops

    Multi Mailbox Ops is a private, local-first control plane for safe multi-account Gmail work from Codex. It preserves source-mailbox identity, removes ordinary mail sending from the V1 tool surface, treats message content as untrusted data, and requires frozen exact-ID plans, identity re-attestation, verification, receipts, and rollback for live mutations. Its two most developed product loops are guarded named-mailbox operations and durable scheduled monitoring/reporting across independently checkpointed mailboxes.

    AI Ops

    Narrative

    01

    A mailbox control plane with a hard edge

    Multi Mailbox Ops makes several Gmail identities operable from one Codex workflow without pretending they are one account. The gateway resolves a human alias to an immutable mailbox record, attests the live provider identity, and keeps ordinary mail sending absent from the V1 capability surface. Mail content is untrusted data; it cannot select tools, expand scope, or grant authority.

    02

    Exact plans, recoverable changes

    Live organization and cleanup work follows a frozen-plan protocol: discover, classify, freeze exact provider IDs and preconditions, review bounded authority, re-attest, execute, verify, and retain a redacted receipt with rollback state. Labels and archive are preferred, Trash is separately bounded and recoverable, and permanent deletion remains unavailable.

    03

    Monitoring that cannot silently consume its report

    Hourly mailbox coverage and scheduled reporting use independent durable cursors. Sanitized outcomes enter a private ledger, exact 9:00 AM and 5:00 PM Eastern reports freeze into reconciled pages, and committed delivery remains in a replayable outbox until a later user-visible acknowledgment proves it was surfaced. Failures and partial coverage remain visible instead of being summarized away.

    04

    Privacy is part of the architecture

    OAuth client material and refresh tokens live in macOS Keychain. The repository and machine-local operation store retain only the minimum non-secret registry, opaque identifiers, synthetic fixtures, policy versions, redacted outcomes, and recovery evidence needed for auditability. Public proof uses fictional report data rather than mailbox screenshots.

    05

    September 11, 2026: native Gmail reassessment

    The source assessment recommended native Gmail for everyday work and freezing custom expansion. It inspected 21 native actions and exercised read access for one mailbox binding, while four-account routing and unattended reporting equivalence remained open. The custom repository still supplied recoverable cleanup receipts, separate coverage and delivery checkpoints, an outbox, draft conflict checks and enforced restrictions. This Mac’s plugin was reported disabled at that checkpoint. These are a dated recommendation and configuration observation, not proof that the system was retired or all accounts migrated. See the linked native-capability review workflow, decision note and creating chat for the comparison.

    System surfaces

    Codex MCP gateway

    Owner-operator using Codex

    Constrained project-specific search, read, preview, organization-policy, and monitoring tools with no ordinary send tool or generic Gmail fallback.

    Focused CLI

    Root operator and maintainer

    Mailbox onboarding, health checks, authority review, exact-plan execution, rollback, and monitor recovery commands for the root operator.

    Identity and operation store

    Runtime safety and recovery

    Machine-local registry, Keychain references, frozen plans, intents, redacted receipts, rollbacks, checkpoints, and delivery outbox.

    Scheduled monitor report

    Owner-operator reviewing scheduled mail changes

    Synthetic-proven responsive report surface with per-mailbox totals, exact message ledger, applied/skipped/failed outcomes, coverage windows, and checkpoint state.

    Repository Context Layer

    Product, engineering, and review

    Product contracts, safety decisions, project checkpoints, synthetic evidence, and deterministic documentation dashboard used as the operational source of truth.

    Implementation stack

    Runtime

    • • Node.js
    • • TypeScript
    • • ES modules
    • • Zod
    • • Google APIs
    • • Model Context Protocol SDK

    Local security boundary

    • • macOS Keychain
    • • Desktop OAuth loopback
    • • immutable mailbox registry
    • • positive endpoint allowlist
    • • root-owned live mutation

    Durable operations

    • • frozen exact-ID plans
    • • policy digests
    • • redacted receipts
    • • rollback manifests
    • • coverage/report cursors
    • • replayable delivery outbox

    Verification

    • • Vitest
    • • TypeScript
    • • synthetic Gmail adapter
    • • forbidden-capability scan
    • • release-package gate
    • • docs determinism
    • • responsive report proof

    Evidence

    21 artifacts grouped by type so each kind of proof can be scanned on its own.

    Data models

    2 artifacts

    Workflows

    3 artifacts

    Images

    4 artifacts

    Chats

    5 artifacts
    chatWork date: Aug 2, 2026

    Building the Gateway and Stopping at the OAuth Security Gate

    Codex implementation conversation that merged the initial repository stack, built the gateway and synthetic safety foundation, configured Google Cloud and Gmail OAuth, rotated a credential exposed during browser automation, and stopped before live mailbox authorization when the Keychain boundary still required remediation.

    1 chat
    chatWork date: Jul 31, 2026

    Designing Multi Mailbox Ops as a Source-Mailbox Gateway

    Foundational Codex conversation that rejected a forwarding-only unified inbox, defined authoritative operations against the original Gmail accounts, established the draft-only and no-send V1 boundary, and created the private Multi Mailbox Ops repository with its first permissions audit.

    1 chat
    chatWork date: Aug 18, 2026

    From Inbox Monitoring to Evidence-Gated Customer-Service Escalation

    Codex operations task showing a newer delegation pattern: one task inherited a complicated return dispute, created a quiet mailbox monitor, recognized when a seller response changed the case, prepared an evidence-backed marketplace escalation, waited for explicit approval before submission, verified the resulting claim state, and kept monitoring the unresolved decision without treating activity as completion.

    1 chat
    chatWork date: Aug 3, 2026

    Hardening Multi Mailbox Ops into a Four-Mailbox Monitor

    Long-running Codex operations conversation that separated clean-main, branch, credential, and live-mailbox truth; fixed the Keychain secret boundary; onboarded and identity-attested source mailboxes; developed controlled organization and monitoring policies; and iterated the recurring report from dense output into a deterministic four-mailbox workflow.

    1 chat
    chatWork date: Aug 7, 2026

    Turning Operator Feedback into Mailbox Reporting and Routing Contracts

    Codex product and implementation conversation that converted a detailed operator critique into totals-first mailbox reports, stable mailbox markers, composable Ecommerce taxonomy, automatic controlled labeling, repository-independent plugin routing, per-mailbox permissions, and a separately gated assistant-mailbox architecture.

    1 chat

    Notes

    7 artifacts
    noteWork date: Date unknown

    product-brief

    Source Summary title: Product Brief - Multi-Mailbox Ops description: One-page product definition for safe Codex-first operation of multiple Gmail mailboxes s...

    1 topic1 scope
    noteWork date: Date unknown

    mailbox-safety-and-approval-model

    Source Summary title: Mailbox Safety and Approval Model description: Normative controls for draft-only, multi-mailbox search, cleanup, and unsubscribe operat...

    1 topic1 scope
    noteWork date: Date unknown

    monitor-report-contract

    Source Summary title: Monitor Report Contract description: Versioned presentation rules for scannable, accessible multi-mailbox monitor reports status: evolv...

    1 topic1 scope
    noteWork date: Date unknown

    organization-policy

    Source Summary title: Durable Mailbox Organization Policy description: Versioned taxonomy and execution rules for consistent agent-driven mailbox organizatio...

    1 topic1 scope
    noteWork date: Date unknown

    decision-log

    Source Summary title: Product Decision Log - Multi-Mailbox Ops description: Durable product and safety decisions for the multi-mailbox operating system statu...

    1 topic1 scope
    noteWork date: Date unknown

    report-preview-desktop

    Source Summary Synthetic mailbox monitor report Report type: Scheduled 9:00 AM report Report window: 5:00 PM-9:00 AM ET (synthetic period) Coverage: Complete...

    1 topic1 scope
    noteWork date: Date unknown

    Native Capability Before Custom Work

    A decision rule from the Gmail reassessment: use native overlap to reduce maintenance, preserve only needed safeguards, and make retirement conditional on real account and reporting evidence.

    3 topics1 scope

    Connected references

    Key dates

    2026-07-31
    Project and safety contract established

    The repository scaffold defined explicit mailbox routing, structural no-send, reversible cleanup, separate unsubscribe authority, and privacy-safe evidence.

    2026-08-02
    Executable gateway and synthetic acceptance

    The TypeScript gateway, local Gmail runtime, Keychain boundary, Codex plugin, frozen workflows, and synthetic safety harness reached a reproducible release gate.

    2026-08-03
    First bounded operational pilots

    Source checkpoints record exact-plan organization and a separately approved limited cleanup/unsubscribe pilot while retaining no-send and no-permanent-delete boundaries.

    2026-08-08
    Durable monitor-report V2

    Independent coverage/report cursors, exact scheduled boundaries, paginated reconciliation, replayable delivery, multi-mailbox bundle proof, and label-drift handling landed on main.

    2026-08-09
    Hyphenomenon project intake

    The project was reviewed from clean source main and prepared as one active project with public-safe workflow, data-model, document, and synthetic image evidence.