Connect any agent to everything.

Every agent you run wants its own connections to your email, calendar, and tools. Connect them once in Executor; anything that speaks MCP, like Claude Code, Cursor, or Codex, points at one endpoint and has them all.

Claude Code

Cursor

Codex

SentryOpenAPI

GitHubGraphQL

LinearMCP

Read docs

You don't have one agent anymore. You have Claude Code, Cursor, a ChatGPT account, something running in a closet. Each one wants its own OAuth into everything, and each one is missing something when you need it.

Executor ends the re-wiring. Connect a service once and every agent reaches it through one endpoint, with every tool in the same shape: one name, one input schema, one output schema.

Every account

All your accounts. Not just one.

Most agent connectors stop at one account per service: one Google login, so your agent sees your work calendar or your personal one, never both. Your flights land in one inbox and your meetings in the other, and no agent can reason over your actual day.

Executor treats accounts as connections: add as many as you have, per service, side by side. Work and personal Gmail, two calendars, a staging and a production Stripe. Every agent you point at Executor sees all of them at once.

Connections · google-calendar

you@company.com work

you@gmail.com personal

Connections · gmail

you@company.com work

you@gmail.com personal

One question — "what does my day look like?" — answered across every account you have.

Context efficiency

Thousands of tools, no bloat.

Connect everything you use and Executor still shows the model a single tool. It searches your catalog and loads a tool's schema only when the code actually calls it, so the prompt never balloons.

Context window

Lower is better

Without Executor1,640 tools · ~278,800 tok

With Executor1 tool · ~1,044 tok

Without Executor

1,640 tools · ~278,800 tok

"You are a helpful assistant.

Your tools are:

createIssue()
listPullRequests()
mergePullRequest()
createRelease()
addLabels()
createBranch()
getCommit()
// + 713 more GitHub tools
createCharge()
createCustomer()
createRefund()
listInvoices()
createSubscription()
capturePaymentIntent()
listPayouts()
// + 503 more Stripe tools
createIssue()
transitionIssue()
addComment()
assignIssue()
listSprints()
createProject()
searchIssues()
// + 233 more Jira tools
listIssues()
resolveIssue()
listEvents()
getProject()
muteIssue()
createRelease()
listAlerts()
// + 163 more Sentry tools
..."

With Executor

1 tool · ~1,044 tok

// the only tool your client sees: "execute"

Execute TypeScript in a sandboxed runtime with access to
configured API tools.

## Workflow

1. const { items } = await tools.search({ query });
2. const path = items[0]?.path;
3. const details = await tools.describe.tool({ path });
4. const result = await tools[path](input);

## Available connection prefixes

- github.org.main: Production GitHub
- stripe.org.main: Live Stripe account
- jira.org.main: Team Jira
- sentry.org.main: Production Sentry

What you get

The model reasons. Executor handles the rest.

One tool shape

MCP, OpenAPI, GraphQL, or a custom integration. Under the hood they all become a tool name, an input schema, and an output schema.

Call it any way

Today it is a code-mode MCP. It could just as well be the Executor CLI, a one-off script, a gen-UI dashboard, or a reusable workflow. Same tools, every surface.

Coming soon 03

Trace every call

One place to see every run and tool call. Audit any decision after the fact.

run_7421 1.42s

sentry.getIssue 184ms

github.searchCode 391ms

linear.createIssue 612ms

Set up once, whole team has it

Per-user credentials and shared ones. No onboarding ritual, no toggling MCPs on and off mid-task.

Destructive actions pull you back in

Executor keeps the semantics it imported: GET vs DELETE for OpenAPI, destructiveHint for MCP, mutations for GraphQL. Agents auto-run the safe stuff and ask before the rest.

Sandboxed execution

Tool calls run in an isolated JavaScript sandbox. Secrets are injected host-side at call time and never enter the sandbox heap, so the agent and model never see a raw token.

Why we built it

Your agent should be able to reach your company's resources in a way that isn't scary. Most setups make you choose between locked down and useless, or wide open and risky.

Executor doesn't care what you add. Once a tool is in that one shape, a name and two schemas, you can call it however you want and the same guardrails apply everywhere. That is the whole idea: make the safe path the easy path.

Get started

Pick your path.

Cloud

executor.sh/cloud

Hosted Executor. Auth, sync, policies, and your whole team online in five minutes. Free tier to start.

Try Cloud →

Looking for self-hosted? →

Desktop

Mac · Windows · Linux

A native app that runs entirely on your machine. Your integrations, credentials, and sessions never leave the device. MIT licensed.

Download for Mac Download for Mac (Intel) Download for Windows Download for Linux

CLI

npm i -g executor

Run Executor as a background service and drive it from your terminal. Best for headless and server environments. MIT licensed.

Read the docs →

View source →

FAQ

Where does my code run, and what touches my credentials?

Tool calls run in an isolated JavaScript sandbox. Credentials are resolved host-side at call time and injected into the outbound request only. They never enter the sandbox heap, the code your agent wrote, the agent, or the model.

Can the agent or the model ever see a raw token?

No. Secrets stay host-side by design. The sandbox calls a tool by name; Executor attaches the credential to the real request outside the sandbox, so a token is never present in anything the model can read.

Can I replace my agents' built-in connectors with Executor?

Yes, and that is the intended setup: connect your accounts in Executor, point each agent at it, and disconnect the per-agent integrations so everything flows through one place. You keep the same tools and gain what first-party connectors don't offer: multiple accounts per service, per-tool policies, and one place to see and revoke access.

What can call Executor?

Any MCP client (Claude Code, Cursor, Codex, and others), the Executor CLI, or a native client you drop in. Because tools share one shape, the calling surface is interchangeable.

How does it know what is safe to auto-run?

Executor preserves the semantics of whatever it imported: GET vs DELETE for OpenAPI, destructiveHint for MCP, and mutations for GraphQL. That tells the agent what it can run on its own and what should pull you back into the loop.

Is it open source? Can I self-host?

Yes. Executor is MIT licensed and built on the SDK we publish to npm. Run the desktop app locally, self-host the server, or use the hosted cloud. Same code paths, different deployment.

Pricing