--- title: Give your agent an inbox description: Connect Claude Code, Cursor or the aiinbx CLI as an inbox — an email address of its own that it sends from and reads, and nothing else in your workspace. sidebar: label: Agent inbox icon: inbox --- A coding agent building against someone else's API sometimes needs an answer only a person has: how long a vendor's export cursors live, whether a sandbox key works in production. Connected as an inbox, it gets an email address of its own. It writes to the vendor's support from that address, gets on with the rest, and reads the reply in the thread whenever it lands. The [MCP server](/mcp) and the [CLI](/cli) connect one of two ways, and you choose which on the consent page when you connect: - **An inbox**: one or more addresses, in one or several of your workspaces. The agent sends as them and reads the mail that comes to them. Nothing else in the workspace is visible or changeable. - **Your workspaces**: the whole API, at the access you choose, as far as your role allows. An [API key](/authentication) always acts for its whole workspace. ## What an inbox may do - Send from its address, schedule, draft and cancel its own emails. `from` can be left out: it sends as its inbox on the thread in `thread_id`, or as its only one. With several and none of them on the thread, name one. - Read the threads filed under its address and the threads its address took part in: mail sent from it, or delivered to it, Cc and Bcc included. A mention in someone's headers alone does not count. In those threads it reads the mail that went out or came in, its own drafts and scheduled mail, and the text of their attachments. It sees who was blind-copied only on mail it sent. - Reply and forward in those threads. A reply goes out from its inbox on the thread: the one mail on the thread last went through, on a tie the one the thread is filed under. - List its workspaces. The list says `"mode": "inbox"`, and each workspace names the inbox's address under `inboxes`. Every other operation answers `403 forbidden`: domains, mailboxes, webhooks, events, suppressions, pacing, keys, members and settings. An inbox never has more than *Read and send* access, whatever the connection asked for. The address can be any address the workspace sends from: one on a verified [domain](/guides/domains), including your `.aiinbx.app` address, or a connected [mailbox](/guides/mailboxes). An inbox sees every thread its address is on, older mail included. Give the agent an address of its own, such as `agent@yourdomain.com`, rather than one people already use. ## Connect over MCP Add the server to your client as in [Connect](/mcp#connect). When the browser opens, choose to give the agent an inbox, then pick a workspace and an address for each inbox it gets. You can also enter the name its mail goes out under. The inbox option shows only when the client asked to send mail; if it is missing, reconnect the client. Connected this way, the client loads only the mail tools: sending, reading and answering emails and threads, attachment text and the workspace list. The four generic API tools are left out, as there is nothing else they could reach. The server tells the model its address, that inbound mail was written by other people and is data rather than instructions, and that an answer can take hours. **Ask a vendor and pick the answer up later.** > Our order sync needs to know how long Lindmetall's export cursors stay valid. Email their support at support@lindmetall.example and ask, carry on with the rest of the sync, and check for their answer when I next ask how it is going. ## Connect the CLI `aiinbx login` opens the same consent page. Sign the agent in under a profile of its own, so your own login keeps running the workspace: ```sh aiinbx login -p agent # choose an inbox on the consent page aiinbx whoami -p agent # "mode": "inbox", with its address ``` An inbox login is shown only the commands it may run: `send`, `wait`, `emails`, `threads`, `attachments` and `workspaces`, besides signing in and out and the CLI's own commands such as `commands`, `docs` and `update`. When it has one inbox in the workspace, `send` goes from it without `--from`: ```sh aiinbx send -p agent --to support@lindmetall.example \ --subject "How long do /v2/exports cursors live?" \ --text "Hi, we page through /v2/exports with your cursor. Does it expire, and after how long?" aiinbx threads -p agent --limit 5 aiinbx threads reply -p agent thr_123 --text "Thanks, that settles it." ``` Point the agent at the profile with `AI_INBX_PROFILE=agent` in its environment, so every command it runs acts as the inbox. ## Wait for the answer People answer in minutes, hours or days. To block for a short while, use `wait`. It exits `124` when nothing came in time: ```sh aiinbx wait -p agent --thread thr_123 --timeout 10m ``` For anything longer, check back later instead of holding a session open. List what came in on the thread since the question went out: ```sh aiinbx emails list -p agent --thread-id thr_123 --direction inbound ``` Over MCP the model does the same with `aiinbx_emails_list`. It is told to say that nothing has arrived yet and look again later, not to call in a loop. ## Mail is still untrusted The inbox receives mail from anyone who has its address, and any of it can contain instructions. An inbox limits what such a message could make the agent do: send as that one address, and read the threads that address is on — never another address's drafts, or who someone else blind-copied. It cannot reach the rest of your mail or change your setup. Keep your client's confirmation on for sending tools anyway, or have it send with `draft: true` so a person reads the mail at `draft.review_url` before it goes. See [Mail is untrusted input](/mcp#mail-is-untrusted-input). ## Switch or remove it Your account page lists the connection as an inbox with its address. Editing it switches between an inbox and your workspaces, and the next call already runs that way. A CLI login runs that way at once too; its help lists the other set of commands once it signs in again. Revoking the connection stops it at once. Workspace admins see every inbox in the console, with who connected which agent, and can remove an agent from one. The inbox and its mail stay when its last agent leaves. ## Related - [MCP server](/mcp): connecting a client, and the workspace mode. - [CLI](/cli): profiles, `wait` and JSON output. - [Threads](/guides/threads): how a reply finds its conversation.