Give your agent an inbox

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.

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 and the 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 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, including your <slug>.aiinbx.app address, or a connected mailbox. 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. 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.

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:

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:

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:

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:

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.

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.

MCP server: connecting a client, and the workspace mode.
CLI: profiles, wait and JSON output.
Threads: how a reply finds its conversation.