This post was originally shared on LinkedIn. I’ve expanded it here with additional context. Airut has since added Slack support alongside email. See airut.org for the current state of the project.
Some weeks ago, while working on a personal project, I asked myself how I would actually want to interact with Claude Code day-to-day. Having to babysit a terminal wasn’t the answer. What if I could email it, move on, and come back to a PR to review later?
I built a first version in an afternoon. Getting the first reply from Claude over email immediately felt right, and I haven’t gone back to the terminal interface since.
Once it was working, I returned focus to the original domain problem — but continued using email to Claude to improve the workflow itself as I hit issues or needed more from it. After about a week I realized the tool could be of interest as a standalone project. A number of email conversations later, it was public as open source.
What Airut does
Airut maps conversations in email or Slack to sandboxed Claude Code sessions. You send a message describing a task. Airut provisions an isolated workspace, runs Claude Code inside a rootless Podman container, and delivers results back in the same thread. When configured, the agent pushes a PR for review. You reply in the thread to iterate; the agent reads your feedback with full conversation context. Multiple tasks run in parallel as independent threads.
The appeal of email and Slack as interfaces is that they already solve threading, search, notifications, and mobile access. There’s no custom client to install, no terminal session to maintain. Starting a new task has near-zero friction — send a message, move on.
Why sandboxing matters
Running Claude Code in fully autonomous mode — without interactive approval for each step — requires real isolation, not just trust. Airut’s security model addresses this at several layers:
Each task runs in a dedicated rootless container with its own filesystem and process space. All network traffic routes through a transparent proxy enforcing a per-repository allowlist with path and method-level rules. Even a compromised agent can only reach pre-approved hosts. Credentials use a surrogate system: the container receives format-preserving stand-ins that the proxy swaps for real values only on scoped outbound requests. The agent never holds usable credentials directly. Network allowlists and container configuration are read from the repository’s default branch, not the agent’s workspace — changes require a merged PR.
The goal is a setup where the agent can operate with full permissions inside a container, but the blast radius of any failure — including prompt injection — is contained by the infrastructure around it.
Where it sits
Connecting agentic LLMs to existing communication tools is not a new idea. Enterprise teams have agents pulling work from issue trackers, and experimental projects like OpenClaw have explored similar territory.
Airut occupies a middle ground. Lower friction than filing issues in a tracker — you just send a message — but with a sandboxing model that I’m comfortable using for real work on projects with credentials and financial data.
The project is open source (MIT), self-hosted, and available at airut.org.