Ravi

emdash + Ravi

emdash + Ravi

emdash is an open-source Agentic Development Environment (ADE) backed by YC W26. It runs multiple coding agents in parallel — each isolated in its own git worktree — across 22 provider-agnostic CLI agents including Claude Code, Codex, Gemini CLI, Amp, Qwen Code, Goose, Cursor, and Cline. You can run agents locally or point emdash at a remote server over SSH and work against remote codebases with the same parallel workflow.

What emdash doesn’t solve is identity and secrets. Twenty-two agents means potentially 22+ API keys scattered across dotfiles, env files, and OS keychains. SSH credentials are stored per-machine. Tokens for Linear, GitHub, and Jira sit wherever whoever set up the integration put them. At scale, that’s fragile — and it’s the wrong foundation for an environment designed to run autonomous workloads.

Ravi is the identity layer emdash is missing.

The Problem

emdash is purpose-built for parallelism. The more agents you run simultaneously, the more the shared-credential model hurts:

  • 22 providers, 22 API keys per machine. Every ANTHROPIC_API_KEY, OPENAI_API_KEY, and GEMINI_API_KEY lives in a config file or shell environment on the local machine. No central store. No rotation. No audit trail.
  • SSH credentials are local and static. emdash stores SSH keys in the OS keychain — which works on one machine but breaks ephemeral CI environments, multi-machine setups, or team workflows where the same remote session needs to be accessible from different hosts.
  • Service tokens have no home. Linear, GitHub Issues, and Jira tokens for ticket ingestion need to live somewhere. Right now, that’s wherever the developer manually placed them.
  • Agents can’t complete autonomous sign-up loops. An agent tasked with registering for an external service, verifying an email, or receiving an SMS OTP has no path forward without human intervention.
  • No per-agent identity isolation. Ten parallel agents share the same credentials. A rate-limit event, a leaked token, or an accidental credential collision affects the entire fleet at once.

What Ravi Adds

1. Centralized API Key Management

Ravi’s secrets vault is the canonical store for every API key emdash needs. Instead of scattering ANTHROPIC_API_KEY and friends across dotfiles and env files per machine, you store them once in Ravi and inject them at session start.

A small shell wrapper or emdash plugin calls ravi_secrets_get before launching, populating the environment with live values pulled from the vault. Key rotation happens in one place — update the secret in Ravi, and every emdash session on every machine picks it up automatically. No plaintext keys. No manual updates across machines.

# Example session wrapper
export ANTHROPIC_API_KEY=$(ravi secrets get ANTHROPIC_API_KEY)
export OPENAI_API_KEY=$(ravi secrets get OPENAI_API_KEY)
export GEMINI_API_KEY=$(ravi secrets get GEMINI_API_KEY)
emdash

With 22 providers supported, this isn’t a minor convenience — it’s the difference between managing a few config files and managing a credential fleet.

2. SSH Credential Provisioning for Remote Sessions

emdash’s remote SSH feature is one of its most distinctive capabilities — run agents against a beefy remote server, review diffs back in the desktop UI. But SSH credentials stored in the local OS keychain don’t travel well.

Ravi can act as the central SSH credential store: provisioned keys live in the vault, injected into ~/.ssh/config or the SSH agent at session start from any machine. Ephemeral CI workers, new team members, and multi-machine setups all authenticate from the same source of truth. When a key needs rotation, it happens once.

3. Service Account Secrets for Ticket Integrations

emdash’s Linear, GitHub Issues, and Jira integrations ingest tickets directly into agent sessions. Those integrations require tokens. Ravi’s passwords and secrets vault is the right home — scoped per workspace, encrypted at rest, and accessible to any agent session that needs them.

Storing integration tokens in Ravi means they’re auditable, shareable across sessions without copy-paste, and revokable without touching config files on disk.

4. Per-Agent Isolated Identities

For agents that need to interact with external services — signing up for accounts, receiving verification emails, completing OAuth flows — emdash’s parallel architecture creates a collision problem. Ten agents sharing one identity will hit rate limits, trip fraud detection, and contaminate each other’s verification inboxes.

Ravi solves this at the infrastructure level. Each parallel agent session gets its own provisioned Ravi identity: a unique email address and phone number, backed by a real mail server and SMS gateway. Agents can:

  • Register for external services autonomously
  • Receive and extract verification codes without human intervention
  • Operate in fully sandboxed environments without credential overlap
  • Maintain persistent, auditable identities that survive session restarts

Setup Guide

Prerequisites

  • emdash installed (download)
  • Ravi CLI configured with an active identity

Step 1: Store your provider API keys in Ravi

# Store each provider key you use with emdash
ravi secrets set ANTHROPIC_API_KEY sk-ant-...
ravi secrets set OPENAI_API_KEY sk-...
ravi secrets set GEMINI_API_KEY AIza...

Step 2: Create a session launch script

Create ~/.emdash-launch.sh:

#!/bin/bash
# Inject Ravi-managed secrets into the environment before emdash starts

export ANTHROPIC_API_KEY=$(ravi secrets get ANTHROPIC_API_KEY)
export OPENAI_API_KEY=$(ravi secrets get OPENAI_API_KEY)
export GEMINI_API_KEY=$(ravi secrets get GEMINI_API_KEY)

# Optionally inject SSH key for remote sessions
eval $(ssh-agent -s)
ravi secrets get SSH_PRIVATE_KEY | ssh-add -

exec emdash "$@"
chmod +x ~/.emdash-launch.sh

Step 3: Store integration tokens for ticket systems

# Linear, GitHub, and Jira tokens for ticket ingestion
ravi secrets set LINEAR_API_KEY lin_api_...
ravi secrets set GITHUB_TOKEN ghp_...
ravi secrets set JIRA_API_TOKEN ...

Step 4: Provision per-agent identities (optional)

For agents that need to interact with external services:

# Create isolated identities for parallel agent sessions
ravi identity create "emdash-agent-1"
ravi identity create "emdash-agent-2"
# Each gets a unique email address and phone number

Each agent session can then use ravi_email_compose, ravi_inbox_email, and ravi_inbox_sms to complete service sign-up and verification flows autonomously.

Why Ravi Fits emdash Specifically

emdash’s value proposition is parallelism at scale — run more agents, on more machines, against more tasks simultaneously. That thesis runs directly into the credential problem: the more parallel the workload, the more fragile shared secrets become.

Ravi isn’t a bolt-on convenience here. It’s the infrastructure that makes emdash’s parallel model safe to run at scale:

  • One vault, many machines. Remote SSH sessions, local workstations, and CI workers all pull from the same source of truth.
  • Per-agent isolation without per-agent setup. New agent sessions get their own identity in seconds, not through manual credential management.
  • Audit trail across 22 providers. Every secret access is logged. When an API key hits a rate limit, you know which session used it.
  • Autonomous loops stay autonomous. Agents that need email or SMS verification to complete a task don’t need to pause for human input — Ravi handles the inbox.

Given emdash’s YC W26 backing and 22-provider footprint, it’s one of the most promising surfaces for Ravi’s agent identity infrastructure to demonstrate real value.

Resources