# CLAWD Mail: An Inbox That Can Research, Create, and Collaborate

*How email, AI assistance, public knowledge, live media, and reviewed Solana actions come together in one workspace.*

An inbox is already a place where work begins. A question arrives, a conversation develops, an attachment supplies context, and someone decides what to do next. CLAWD Mail builds on that familiar sequence. It gives an AI agent its own email address, lets people work with it through ordinary conversations, and connects those conversations to research, image creation, live collaboration, and carefully reviewed on-chain actions.

The innovative part is the relationship between those capabilities. A useful agent needs a way to receive work, enough context to respond, a clear identity, and limits on its authority. CLAWD Mail implements those pieces across a private mailbox, a durable responder, a reviewed writing assistant, and services that expose their status and permissions. The result is a practical proposal for an agent workspace: start with a conversation, carry useful context forward, and make consequential decisions visible to the person responsible for them.

Email makes that proposal approachable. After account approval and inbox creation, a user can talk with CLAWD without leaving the website open or adopting a new messaging protocol. A normal email thread becomes the interface for asking questions, requesting research, sharing a supported image, or preparing an idea. Original messages and attachments remain available in private storage, so the conversation has a record that people can inspect.

The application also provides a conventional mail experience: owned inboxes, threaded conversations, composing and replying, incoming and generated attachments, and account settings. Its lobster artwork and Solana-inspired visual identity give that experience a recognizable character. Small details support everyday use, including an incoming “You've got mail!” cue, a whoosh after an accepted outgoing message, and account-specific controls for muting or previewing those sounds. These cues run while the app is open and respect browser audio restrictions; they complement the delivery status shown in the interface.

CLAWD Mail offers two distinct ways to use AI. **Ask Claude** is a writing assistant powered by `anthropic/claude-haiku-5.5` through OpenRouter. A user explicitly requests a draft, reply, or conversation summary and watches the answer stream into a review panel. Applying a draft changes the editor body. Sending remains a separate action. The assistant receives the selected message or owned conversation and the user's instructions; it receives no attachments and has no tools for sending mail or performing actions. Completed results are saved privately so users can reopen them.

The **CLAWD email responder** serves a different purpose. A separate continuous worker uses xAI `grok-4.7` to answer eligible incoming messages in enabled inboxes. It can use web search, curated skills, public Solana research, supported source-message images, and requested image generation with `grok-imagine-image-2.0`. It replies to the original sender within the email thread. Owners can edit the agent's name and character instructions, inspect reply status, and pause an owned inbox. New approved inbox configurations default to enabled; installations can also include historical received mail through the documented backfill setting. Understanding that setting matters when activating an inbox that already contains conversations.

These two interaction styles let users choose the right amount of automation for the task. Someone writing a sensitive message can request assistance, revise the result, and decide when to send. Someone who wants an ongoing research correspondent can enable CLAWD and converse by email. The distinction is implemented in the controls and backend behavior, making the agent's role easier to understand.

The responder's engineering also addresses a less glamorous but essential problem: what happens when a process restarts or a provider times out? PostgreSQL records each eligible message and its job state. Workers claim jobs through leases, reuse saved generated responses where appropriate, and check approval before private work and dispatch. Loop detection excludes automatic replies, bounces, and other unsuitable messages. If a send may have been accepted but its outcome cannot be proved, the job becomes ambiguous and is not automatically resent. That design reduces the risk of duplicate communication while preserving uncertainty for review. It does not pretend that every distributed operation can be made exactly once.

Research gains another dimension through the shared **Hookedpad knowledge** feature. CLAWD Mail runs a bounded scheduled crawler over public Hookedpad launch pages and indexes the resulting snapshots in Supermemory. Approved users can search the same knowledge from their account, and the email agent can retrieve dated excerpts with source links. Stable document identities and content hashes avoid repeatedly indexing unchanged material; submitted pages and indexed pages have distinct states.

The scope of this knowledge is deliberately specific. It contains public website snapshots, rather than a personal memory of every user's mailbox or files. Crawl dates help users assess freshness, and current chain questions can use separate Solana tools. The crawler honors `robots.txt` and limits the pages and content it processes. This is an example of useful shared knowledge with an understandable source and boundary: everyone can benefit from the public research without quietly turning private correspondence into a shared dataset.

For Solana questions, CLAWD can inspect public wallet holdings, transaction details, and token information through configured server connections. Responses can identify the source, observation time, commitment, and slot when available. Live launch feeds and market prices remain observations, with timestamps and unavailable states. A relay event can be useful context without becoming a confirmed transaction receipt. The mail research tools do not sign transactions, transfer funds, purchase tokens, or request wallet secrets.

The on-chain launch flow shows how an agent can prepare consequential work while the application retains a clear approval boundary. A sender can email an enabled inbox with a coin name, symbol, description, and supported image, or a published metadata URI. CLAWD prepares a Pump.fun launch draft and returns a review link. An inbox-scoped OpenDots MCP connection can prepare drafts too; its tools do not approve or sign a launch.

The signed-in, approved owner of the receiving inbox then creates and funds a **server-managed Privy launch wallet**. This wallet is controlled through the installation's server authorization and is separate from the user's existing external wallet. The application simulates the proposed transaction and displays the mint, fee recipient, and estimated cost. The owner approves that exact review within its 45-second window, subject to a 0.05 SOL total cost ceiling. The implemented flow creates a standard SOL-paired Token-2022 coin without an initial buy or the optional mayhem, cashback, and holder-reward modes. Preparing a draft can publish its image and description through Pump.fun's IPFS service, so those launch assets should be intended for public use.

Receipts matter after approval as well. The signed transaction and public signature are saved before broadcast. A network timeout leaves a submitted transaction available for inspection; refreshing checks its existing signature instead of creating another coin. The application displays a coin link after successful confirmation and the relevant on-chain account checks. Creator-fee collection follows a separate review and approval flow into the same launch wallet, including supported bonding-curve and PumpSwap fees and retained fees that need sweeping. Expected income, costs, and destination are shown before approval. Email and MCP draft preparation do not authorize that claim.

Live collaboration extends the workspace beyond asynchronous messages. **CLAWD Solana Live**, available at `/stream` after sign-in and account approval, provides a directory of discoverable broadcasts and shareable room links. Approved account holders can host or watch rooms. Cloudflare RealtimeKit supplies the actual stage, with custom controls, chat, participant management, and local video effects. Camera and microphone start off, and joining is explicit. Unlisted rooms are accessible to approved signed-in viewers with the link, which makes them convenient to share but unsuitable for treating as private mail.

AI takes two forms within this live experience. CLAWD Guide and Solana Scout provide explicitly requested text assistance; Scout's research tools are read-only. A host can separately start a disclosed CLAWD Voice or CLAWD Vision participant, using the host's enabled microphone and selected camera or already shared screen. A private GetStream Vision Agents runtime combines xAI speech with bounded visual understanding. The companion's generated voice enters the room as a real participant. Visual analysis runs when requested or prompted by a visual question, sessions are limited, and the application does not save the companion's audio or frames. The companion has no signing, trading, or payment tools. Provider processing still occurs when the host enables it, so the media source and participation choice remain meaningful controls.

A separate Solana wallet plugin allows an explicit Wallet Standard connection or observation of a public address. It reads public account information and never calls signing, payment, or broadcast methods. This external-wallet observation feature has a different authority model from the server-managed Privy launch wallet, and the product makes both roles useful without conflating them.

Consider a creator developing a new community project. Once approved, they create an inbox and email CLAWD a research question. The agent can return public launch-page excerpts and verified public-chain details with their sources. The creator requests an illustration, then supplies the final name, symbol, description, and artwork for a launch draft. They open the owner review, inspect the wallet and cost, and make the launch decision themselves. Later, they can host a public room, invite viewers, and explicitly enable a voice or vision companion to discuss a shared view. Each stage has an interaction that fits its purpose: email for asynchronous preparation, a private account page for transaction approval, and a visible room participant for live assistance.

The privacy model supports that workflow through individual accounts and ownership checks. Documentation, privacy, terms, and the service description are the four public product pages. Login remains an access utility; other product pages require actual authentication, with approval and ownership enforced for private actions. New signups wait for owner approval before accessing private mail, files, or agent features. Approval is checked on private requests and before responder work; approving a member does not give that member another user's inbox. Neon stores identity, membership, ownership, and job metadata, while private Cloudflare R2 storage holds mail and files. Incoming HTML is sandboxed, with scripts and external tracking resources blocked. Provider credentials remain server-side.

Private storage does not mean end-to-end encryption or that no third party processes content. Requested writing assistance sends selected text to OpenRouter, enabled automatic replies use relevant mail context with xAI, and the live companion processes the host's selected media. Streaming avatars and backgrounds are public sharing assets, and launch metadata is published. These distinctions make user control concrete: users can understand which information is private application data, which information goes to an enabled provider, and which assets become public.

The capabilities described here are implemented in this repository. Their availability depends on configured providers, account approval, active workers, wallet funding where required, and provider access or quotas. A successful build or a fixture test does not establish real email delivery, live media, or a funded mainnet action. The project includes separate verification procedures for those flows and exposes unavailable, failed, pending, and uncertain states in the application. See the [documentation](/docs), [privacy policy](/privacy), [terms](/terms), [service description](/service), [setup guide](README.md), [mail agent](docs/MAIL-AGENT.md), [writing assistant](docs/ASSISTANT.md), [public knowledge](docs/SUPERMEMORY.md), [launch flow](docs/PUMP-LAUNCH.md), [creator fees](docs/CREATOR-FEES.md), and [streaming guide](docs/STREAMING.md) for the operating details.

CLAWD Mail's contribution is a coherent way to move from conversation to useful work. An agent has a reachable address, research has traceable sources, automation has durable status, media participation has explicit consent, and on-chain execution has a separate owner decision. Bringing those ideas into a familiar inbox gives people a practical place to explore what capable agents can do while keeping their role in the workflow visible.