Executor 2 is the beta of an MIT-licensed gateway that lets every agent you use share one set of tools. You connect Gmail, GitHub, Linear or any MCP server, OpenAPI spec or GraphQL API to Executor once. Claude Code, Cursor, Codex and other MCP-capable agents then reach that same catalog through a single connection, with a policy per tool: always allowed, needs approval, or blocked. Beta builds 2.0.0-beta.35, .36 and .37 shipped on November 3, 4 and 5, 2026, according to the project's GitHub releases.
The repository has about 4,300 stars at the time of writing, and the Executor site says the project is open source and backed by Y Combinator. It is a beta, so expect change. This guide covers what it does, how to run it, and the risks you should check first.
The problem Executor tries to fix
Every agent keeps its own list of integrations. If you use Claude Code, Cursor and a chat app, you paste the same API keys in three places, wire up the same MCP servers three times, and have no single view of what each tool is allowed to do. The README puts it directly: "Add a tool once, give it credentials once, set its policy once, and every agent shares it over MCP."
If you are new to the protocol, our guide to the Model Context Protocol explains how an agent calls tools, and the dictionary entry gives the short definition. Executor sits between the agent and those tool servers.
Agent tool belt illustration showing several tools held in one place, as an MCP gateway like Executor shares one catalog with every agent
How it works
The README describes four steps:
- Add an integration. An MCP server, an OpenAPI spec or a GraphQL API. Google Discovery documents are also supported, and a plugin system is open to other types.
- Create a connection. One configured, optionally authenticated instance of an integration. One integration can have many connections, for example a personal and a work Google account.
- Set policies. Each tool is allowed, gated behind approval, or blocked. The README says defaults are derived from the spec.
- Point your agents at Executor over MCP. They all share the catalog.
The site adds a second idea: agents can write new tools and small apps on top, such as a scheduled job that copies new Stripe customers into Notion, or a webhook that files a Linear ticket when a Sentry issue spikes. Those examples are the project's own illustrations. We have not tested them.
One design point stands out. Executor says tool calls run in a sandbox and that credentials never end up in chat or in code, because you connect each account once through a secure link. Several outside sources describe the "code mode" approach, where the agent gets a runtime to call tools in code instead of loading every tool schema into its prompt. That idea targets context cost. See our post on how tool descriptions affect selection reliability for why too many tool schemas hurt agents.
What is in the 2.0 beta
The beta release notes, which are the primary source we read, describe:
- One executable. Built with Bun, with the dashboard, app framework, workerd, Git and a native credential-store binding beside it. The notes say it needs no source checkout, Node, Bun or 1Password on the user machine.
- A background service. Running
executorstarts the service or joins the one already running, and opens the dashboard. It keeps running untilexecutor service stop, and nothing starts it with the operating system. - Daily update checks. The CLI checks npm daily and suggests
executor upgrade. SetEXECUTOR_NO_UPDATE_CHECK=1to skip it.executor upgrade --rollbackreturns to the previous version for script installs. - Separate data. The beta uses
~/.executor/v2/cli, separate from Executor 1 data. One server runs per data directory. The default port is 4312, changeable withEXECUTOR_PORT. - Desktop app. It shares the same directory and background service, and moves older desktop data into place on first launch.
- Pairing.
executor pairproduces a new browser connection link.
The main-branch README still shows commands such as executor install and executor web, and an MCP endpoint on port 4788. The beta notes describe a different flow and port. Follow the release notes for the build you install, and check the docs if the two disagree.
How to try it
From the beta release notes:
npm i -g executor@beta
executor
Without Node, the notes give an install script: curl -fsSL https://executor.sh/docs/install.sh | sh on macOS or Linux, or irm https://executor.sh/docs/install.ps1 | iex in PowerShell on Windows. Each release attaches its archives and a SHA256SUMS file, so you can check the download.
To connect an agent, the README suggests the add-mcp helper, which detects the client and writes its configuration. The dashboard has a Connect card that shows the exact command for your port. Most MCP clients only load servers at startup, so restart the client or open a new chat before the tools appear.
If you prefer not to run anything, the README says Executor Cloud has a free tier and works with cloud agents such as ChatGPT. Treat that as the project's description, and check the site for current limits.
Connector access scopes illustration showing limited permissions per connected account, matching Executor's allow, approve or block policy per tool
Credentials: what the release notes say
A gateway that holds many logins needs a careful storage story. The notes say that on first launch Executor saves its API and encryption keys in the operating system credential store: macOS Keychain, Windows Credential Manager, or Linux Secret Service. If no store exists on a directory's first start, keys go to keys.json in the data directory with mode 0600, and the path is printed to the error stream. If a store exists but is locked or denied, startup stops without a key file.
For headless installs, you supply EXECUTOR_API_KEY (32 or more characters) and EXECUTOR_ENCRYPTION_KEY (64 hexadecimal characters) from a secret manager. Executor never saves supplied keys. The notes also warn that copying the data directory alone is not enough to recover an install: you need the matching OS credential or key file too, so back up both.
None of this is an audit. We did not review the code or run a security test. Treat the notes as the project's design, not a guarantee.
Risks to weigh before you adopt it
- One place to attack. If all your agents share one gateway, one compromise reaches every connected account. That is the trade for convenience. Keep the service on localhost, or protect any remote endpoint.
- Policies are only as good as you set them. The default derived from a spec may allow tools you would rather gate. Review the list, block delete and send actions, and require approval for anything that spends money or writes data.
- Agent-written tools. Letting an agent write new tools is powerful. It also means code you did not write can call your accounts. Read what it generates before enabling it.
- Beta software. Builds ship daily. Data layouts and commands may change before the stable release.
- Testimonials are not evidence. The project site shows many user posts praising it. Those are the vendor's selected quotes. Judge it by your own test.
If you give agents access to real accounts, a runtime check helps. AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions. For the wider picture, see our MCP security guide.
A safe first test, step by step
- Install the beta on a machine you can wipe, using the checksum file that ships with each release to verify the download.
- Add one low-risk integration first, such as a public OpenAPI spec like the Petstore example in the README, so you can watch how tools are indexed without any private data involved.
- Open the policy list and confirm that every write or delete tool is set to approval or blocked.
- Connect a single agent over MCP and call one tool. Confirm the approval prompt appears when it should.
- Only then add a real account, preferably a secondary one, and repeat the check.
- Note the data directory and credential entry so you can back them up and remove them cleanly if you drop the tool.
Who it fits
A good fit: developers who run two or more agents and are tired of repeating keys; teams that want one shared, reviewed catalog; people who want an approval gate on specific tools.
Not yet: anyone who needs a stable, audited product for regulated data. Wait for the stable release and read the code.
Compare: the hosted connector systems from big vendors, such as the one in our report on Google's connected apps platform, tie you to one ecosystem. Executor aims to work across agents, but it is a young project from a small team.
What to watch
- The move from beta to a stable 2.0 release and its migration notes.
- Any independent security review of the gateway and its sandbox.
- Whether the cloud tier's pricing and limits stay as described.
- How agents from the big labs handle a shared gateway as their own connector systems grow.
Bottom line
Executor 2 beta is a real, MIT-licensed project with active releases, a clear idea and a sensible credential design on paper. If you juggle several agents, it can replace a lot of copy-pasted configuration with one catalog and one policy list. Try it on a throwaway account first, set policies before you connect anything sensitive, and expect the commands to change before the stable release.