Unified asynchronous inbox and bounded access through client identities

v2.1.0 reconciliation — 20 September 2026

Implemented in the release, with live acceptance still outstanding:

• Durable Inbox/SMTP acceptance and IMAP bridge (#1824), then Home on the same queue (#1825).
• Assistant compose creates a web thread instead of sending mail; own-sender notification suppression and participant alias cleanup (#1840). Older conversations accidentally sent as mail are not migrated.
• Home is the assistant workspace; Inbox assistant entries reopen it, while correspondence stays in Inbox (#1841). Working status appears under the agent name (#1847).
• Existing thread titles are editable (#1846). The current design uses the first message as the initial title; the older proposal below for an upfront subject field is superseded.
• Named agents retain /agent/ (#1848). The sidebar/history UI was subsequently removed (#1863); do not restore it from older issue notes.
• Current navigation is Home / Account / Admin / Inbox / Logout; Blog is in the footer. Inbox has Messages / Scheduled / Saved / New message in one row (#1835, #1863–#1865).
• Bounded Hello email introduction and verified-account continuity exist (#1849). This is not general anonymous web/SMS/WhatsApp access. The address is no longer promoted on Home or About (#1852, #1854).

Next: verify accepted-request recovery across disconnect/restart, duplicate submission, IMAP reply routing and flags, incoming-only notification delivery (#1808), and draft/focus preservation on real clients. Keep the broad acceptance checklist open until verified. Provider-currency hard budgets and general provisional identity remain outstanding. Follow priority tracker #1804; subscriptions are #1867.

Earlier implementation notes below are historical wherever they conflict with this release status.

---

Product contract

The Inbox belongs to the person. Micro helps with requests deliberately addressed to it. Keep the web a sparse mail-like client over the same durable conversations exposed through other clients. Existing email/phone should be enough to begin; adopting a new email address is optional. No dashboard expansion or second message store.

Execution order

1. Repair the existing clients

• Include web/CLI assistant conversations in IMAP; keep actual outgoing user messages in Sent and assistant answers incoming. Preserve ownership, held-message exclusion, stable message IDs and mail deduplication.
• Make reply routing explicit and owner-authorised; replying from IMAP must continue the original conversation, not start an unrelated thread or send to a fabricated external address.
• Audit read/unread, delete/expunge and IDLE updates for bridged messages; persist acknowledged changes and do not silently report unsupported mutations as successful.
• Keep a compact reply composer visible. Use Ask Micro for help with third-party correspondence; ordinary assistant conversations need no Assign action.
• Update web lists and open conversations automatically without resetting drafts, focus, selection, scroll or pagination. Hidden/offline clients pause and resume cleanly. No refresh link as the normal delivery path.

2. One durable asynchronous acceptance path

• Reuse current thread/work infrastructure: persist message and pending execution before acknowledging acceptance, with stable client message ID and owner-scoped deduplication.
• Keep queued/running/needs-input/completed/failed state and result on the originating conversation. A task is an explicit goal, not a replacement for every chat reply.
• Resume queued work after restart. Interrupted side effects need reconciliation or an honest blocked state, never blind replay. Retry delivery separately from execution.
• Bound per-account and instance concurrency, queue depth, input/output/context sizes, tool steps, lifetime and retries.

3. Client identity without a mandatory signup form

• Distinguish client address, proof of control, provisional principal, durable account, conversation and delivery destination.
• Web: cryptographically random server-issued session cookie (HttpOnly/Secure/SameSite), expiring provisional records and CSRF/origin protections. A caller-supplied session ID or user agent is not identity.
• SMS/WhatsApp: validate provider webhook signature, destination and message ID before trusting the supplied number. A phone number is an identifier, not a permanent person; handle reassignment, recovery and linking explicitly.
• Email: a From header is not ownership proof. Use the existing verified mapping or a bounded verification challenge; SPF/DKIM/DMARC signals alone do not entitle a sender to another account's private data.
• Linking an identifier to an existing account requires proof and explicit linking. Never merge histories based on matching names, claimed addresses or model suggestions. Atomically transfer owned provisional conversations after verification.
• Before verification allow only a separately budgeted, minimal capability set: no personal connections, private retrieval, external sending, expensive browser/code/image tools or autonomous jobs.
• Define expiry, deletion, return-device behaviour and what is lost when a guest cookie is cleared. No fingerprinting or IP-based account identity.

4. Hard cost and abuse boundaries before anonymous inference

• Anonymous model access stays disabled until the budget gate is implemented and configured.
• Persist reservations before every paid operation. Enforce per-principal allowances plus an independent instance/provider budget that cannot reset by clearing cookies, rotating sessions or creating accounts.
• Bound output tokens and tool costs; cap outstanding reservations and concurrent work. Product credits are not a provider-currency hard ceiling: use conservative cost reservations and provider-side limits where available.
• Verification emails/texts also need bounded delivery, deduplication and budgets; never create a reply loop or amplification channel.
• When the public pool is exhausted, fail before provider calls and preserve drafts. Keep ordinary pages, login and logout reachable. No blanket IP throttling or trusting user-agent strings as identities.
• Record non-content usage/cost signals and provide an operator kill switch; assess sustainable allowance using actual observed costs.

5. Assistant behaviour and authority

• An authenticated instruction starts permitted work; a forwarded message with an instruction supplies context. Without a clear instruction, ask briefly what is wanted rather than taking consequential action.
• Untrusted quoted/forwarded content never becomes authority. Ordinary mail from another person does not automatically grant model access or permission to act.
• Acknowledge only when useful, report concrete outcomes in the same thread, and keep already-authorised routine work free from repeated approval friction.

Separate provider evaluation

Codex App Server remains #1793. Confirm supported hosted/multi-tenant use, model availability, grant terms, credential isolation and cost limits before any integration. A free grant is not assumed to cover anonymous public traffic. No provider switch is part of the IMAP repair.

Acceptance

Two independent accounts and a provisional identity; same-conversation replies on web and IMAP; arrival without refresh; no cross-owner access; draft preserved on failure; duplicate submission; queue acceptance and restart; budget exhaustion before provider work; revoked identity cannot resume private work. No tests or live outbound messages without the applicable authorisation; use source/build checks now and state unverified live behaviour explicitly.

Related: #1804 (delivery/reliability), #1808 (notifications), #1471 (chat/IMAP contract), #1821 (groups), #1653 (privacy). This records the implementation sequence, not a claim that guest access or durable web acceptance is already shipped.

First implementation — PR #1824

Merged: web/CLI conversations in IMAP; assistant answers incoming; owner-scoped conversation reply addresses; persisted asynchronous acceptance for SMTP assistant replies and web Inbox replies; queued/running UI state; per-submission deduplication receipts for seven days; explicit interrupted outcome rather than side-effect replay. Startup flow adoption now recognises existing conversations rather than creating a duplicate for each queued reply.

The shared web client updates lists and messages automatically, leaves composers mounted, preserves drafts on submission failure, and uses visible reply fields and Ask Micro wording. IMAP read flags and expunge persist in its mailbox view; deleting a bridged message deliberately preserves the source conversation. IDLE/NOOP report removals and arrivals; newly exposed historical messages follow assigned UID sequence order.

Limits: one executing queued reply, four pending per account, 64 globally, 8,000-character prompts, bounded receipt storage. The existing 200-thread/50-message IMAP bridge window remains. XMPP person-to-person replies still use an XMPP client. Landing/direct API/channel execution has not all moved to this queue. This does not implement provisional accounts, anonymous inference, cross-client read-state synchronisation or a provider-currency hard cap.

Validation: local Go build, JavaScript syntax and diff checks passed; GitHub build passed; three review findings resolved. No tests run. Live IMAP/restart/browser verification remains outstanding. Keep the broader acceptance checklist open until those behaviours are actually verified.

Completion and conversation purpose

A request acknowledgement is not a completed task. Keep responsibility attached to the original conversation until there is an outcome, an explicit failure, or a specific question/approval needed from its owner. Preserve that state across disconnects and restarts. Do not leave people following internal commands or detached task links to discover what happened. Finish one implementation slice through review and deployment before expanding scope.

Next UI slice, after durable landing acceptance: make the existing thread subject usable. Offer an optional, compact Add a subject control when starting a web conversation; preserve the first-message fallback; allow the owner to edit a thread's subject and show it consistently in the conversation and Inbox. Retain existing email subjects. No model-generated titles, mandatory extra field, new destination, or second conversation store. A subject describes the purpose of the dialogue; it must not acquire system-instruction authority. Consider the welcome/example space for this optional context without turning the landing into a form-heavy page. Implementation and mobile layout verification remain outstanding.

Durable landing — PR #1825

Merged and deployed. The landing now submits to the same durable reply queue, checks for formatted answers after acceptance, and recovers pending replies after refresh. Owner-scoped message identifiers deduplicate retries and anchor response polling. Structured tool results are preserved. Execution is bounded to four concurrent accounts, one queued reply executing per account; the earlier single-worker limit is superseded. Queued work and interruption handling use the existing restart policy.

Validation: Go build and JavaScript syntax checks passed, both review findings resolved, GitHub build/deploy succeeded, and the live landing/script served the updated client. No tests run; authenticated end-to-end and deliberate restart verification remain outstanding.

Product refinement: the message and Inbox are primary. Secondary transport links should live in Contact/account connections, rather than being advertised under the landing prompt. Label the Inbox view Messages, and include Blog after Home in the shared desktop/mobile navigation. The navigation/label cleanup is a separate small change; editable subjects remain the subsequent UI slice.

Navigation cleanup — PR #1826

Merged and deployed: Blog follows Home in the shared desktop/mobile navigation; Inbox Conversations is now labelled Messages; secondary channel links were removed from the logged-in and logged-out landing. Contact and account connection details remain. The editorial Blog exception is recorded in AGENTS.md following the explicit product decision.

Validation: build/deploy succeeded; the deployed public landing was inspected visually on desktop and Blog opened successfully without login. No test suites run. Mobile and authenticated visual checks remain unverified. Optional subject creation/editing is recorded above and has not yet been implemented.

Start with the current web/CLI conversation flow, IMAP bridge, SMTP acceptance path, and shared durable queue described in the issue; distinguish shipped work from the outstanding acceptance checklist. Run the listed Go build, JavaScript syntax, and source checks before attempting live verification. Done means the specified cross-client recovery, routing, deduplication, notification, draft-preservation, ownership, and budget behaviours are verified without cross-owner access.