TL;DR: Executor is your tool gateway. Connect every service and every account once, set per-tool permissions, and any MCP-compatible agent (Claude Code, Codex, Cursor, whatever ships next) reaches all of it through one endpoint. Try it at executor.sh.

https://youtu.be/NWYFpDW02Dw

The problem

You don't have one agent anymore. You have Claude Code, a ChatGPT account, Cursor, maybe a box in the corner running jobs overnight. Three problems follow:

1. Every agent wants its own OAuth into everything. You connect your calendar to the tenth harness in a slightly different way, tokens expire, connectors deprecate, and each agent is missing something when you need it.
2. Most connectors stop at one account per service. One Google login means your agent sees your work calendar or your personal one, never both. Your flights land in one inbox, your meetings in the other, and no agent can reason over your actual day.
3. Permissions are an afterthought. Once an agent holds a token, it can do anything that token allows. Giving an agent your email shouldn't mean trusting it to never hit delete.

What Executor does

Connect once in Executor, and sever all the one-off connections.

Each integration gets credentials plus a per-tool policy: always allowed, needs approval, or blocked. Point any MCP-compatible agent at Executor and it has everything.

• All your accounts, not just one. Accounts are connections: work and personal Gmail, two calendars, a staging and a production Stripe, side by side. Every agent sees all of them.
• One tool shape. MCP, OpenAPI, and GraphQL integrations all normalize into a consistent name + schema. 1,600+ tools collapse into a single ~1k-token surface instead of ~280k tokens of tool definitions.
• Safe by default. Executor preserves operation semantics (GET vs DELETE, destructive hints, GraphQL mutations), so agents auto-run safe operations and ask before risky ones.
• Sandboxed execution. Tool calls run in an isolated JavaScript sandbox; secrets are injected host-side, so the model never sees a raw token.
• Team-ready. Per-user and shared credentials. Onboard the team once, not per agent per person.

Because enforcement lives in Executor rather than in any agent framework, you can adopt whatever new agent ships next week without re-thinking data access. You keep everything first-party connectors offer and gain what they don't: multiple accounts per service, per-tool policies, and one place to see and revoke access.

How to use it

• Local: open-source (MIT) desktop app and CLI, everything stays on your machine
• Self-hosted: a Dockerfile that lets your team own all its data
• Executor Cloud: hosted, nothing to manage

Traction

• 2,800+ GitHub stars, ~14k npm downloads/week, ~3,000 users on the local version

Background

Solo technical founder, previously at Vercel. Before Executor I built answeroverflow.com and grew it to 1.5M monthly users as a solo dev, bootstrapped.

Asks

1. Try it and tell me where it breaks. executor.sh has a "Copy prompt" setup you can paste into your agent to get started.
2. Intros: if your team (or one you know) is drowning in per-agent integration setup, I'd love an intro: rhys@executor.sh
3. Star the repo: github.com/UsefulSoftwareCo/executor
4. Want a walkthrough? Grab a time: cal.com/rhys-sullivan/executor-chat