Aizen

Aizen is a native macOS workspace for parallel agentic development. Each project or git branch gets its own isolated environment: terminal, file browser, built-in browser, agent sessions, and MCP servers — all scoped per worktree, not per app. It ships with Claude Code, Codex, and OpenCode as default agents and includes a built-in MCP marketplace.

Why Ravi

Aizen is built for agents that do real work on the open web — signing up for services, handling OAuth redirects, completing email verification flows, scraping behind login walls. The built-in per-environment browser exists precisely because agents hit auth flows constantly.

Without real identities, those flows break. A Ravi identity gives each Aizen workspace a real email address, a real phone number, and an encrypted credential vault. The agent can receive verification links, retrieve SMS OTP codes, and pull stored passwords — all via tool calls, without leaving the workspace or asking a human for help.

The per-environment isolation in Aizen maps directly to Ravi’s identity model: each agent persona is a distinct, auditable entity. One workspace, one identity. No credential bleed between branches.

Integration Points

Per-environment Ravi identities — Each Aizen workspace can be assigned its own Ravi identity at creation time. The agent working on feature/payments uses a dedicated identity, not the shared global one. Staging credentials stay in staging; production credentials stay in production.

Auth flows in the built-in browser — When an agent hits a signup or OAuth flow inside Aizen’s browser, it needs a real email to receive verification links and a real phone for SMS OTP. Ravi delivers both. The agent calls ravi_read_email to get the verification link or ravi_inbox_sms to retrieve the OTP code, then completes verification autonomously.

MCP integration path — Aizen has a per-agent MCP marketplace. Adding Ravi as an MCP server lets any agent in any Aizen environment access email, phone, passwords, and secrets via standard tool calls — no custom plugin required. This is the lowest-friction distribution path for teams already using Aizen.

Credential vault per project — ravi_passwords_* and ravi_secrets_* keep service credentials scoped to the project context. API keys and login credentials stay with the workspace that needs them, not in a global config file.

Setup Guide

1. Install Ravi as an MCP Server in Aizen

Open Aizen, navigate to the MCP marketplace in the agent panel, and search for Ravi. Add it to your agent environment. Each environment can have its own Ravi MCP configuration.

If installing manually, add the Ravi MCP server to your agent’s tool config:

{
  "mcpServers": {
    "ravi": {
      "command": "npx",
      "args": ["-y", "@ravi/mcp-server"],
      "env": {
        "RAVI_API_KEY": "<your-ravi-api-key>"
      }
    }
  }
}

2. Provision a Ravi Identity for the Workspace

Create a dedicated Ravi identity for each Aizen environment using the Ravi dashboard or API. Treat it like provisioning a service account — one identity per project context.

3. Handle Auth Flows Autonomously

When your agent triggers an email verification flow inside Aizen’s browser:

# Agent checks for the verification email
ravi_inbox_email(unread=true)
# → finds the verification thread
ravi_read_email(thread_id="...")
# → extracts the link from text_content and follows it

For SMS OTP:

# Agent retrieves the code after triggering SMS verification
ravi_inbox_sms(unread=true)
ravi_read_sms(conversation_id="...")
# → matches /[0-9]{6}/ in message body and submits it

4. Store Credentials After Signup

After an agent completes signup for a service inside an Aizen workspace, store the credentials immediately:

ravi_passwords_create(
  domain="service.com",
  username="agent@ravi-identity.com",
  notes="created in aizen/feature-payments workspace"
)

This keeps credentials retrievable in future sessions without re-authenticating.

What This Enables

An Aizen agent with a Ravi identity can work the full cycle autonomously: discover a service, sign up, verify the email, complete OAuth, store the credentials, and use them in subsequent sessions — without human intervention at any auth step. Combined with Aizen’s per-environment isolation, this means parallel agents can maintain separate, non-conflicting service accounts for the same external tool.