Let your AI work where your code already runs.
Website · Docs · Dashboard · CLI releases · Self-hosting
Exeora turns a project on a server, a VM, a build box, a Raspberry Pi, the laptop in front of you, or Exeora Cloud into one MCP URL. Claude, ChatGPT, Cursor, VS Code, Copilot and every other MCP client can then read, edit and run it right there, under rules you set.
No port to open. No source code to upload. No tunnel to wire up. Free for 10 machines and 2 Cloud instances.
curl -fsSL https://exeora.dev/linux/install.sh | sh
exeora connect
exeora project add the-project-you-want-to-serveconnect signs you in, registers the machine, and keeps the outbound connection open. It does not have to be run from a project directory. exeora project add registers a directory to serve. Point any client at the printed MCP URL and leave connect running.
A project is a repository, and it lives in one or more locations: your machines and Exeora Cloud. One location is the default, where a call that names no workspace lands. Running exeora project add in a checkout whose remote is already a project joins that project as one more location. With GitHub connected in the dashboard, a project can also be added by picking a repository from a list and letting Exeora Cloud hold it, with no machine of yours switched on. See projects, locations and workspaces.
Contents: Why Exeora · How it works · Compare · What you get · Tools · Beyond tool calls · Clients · Install · Plans · Documentation · Contributing
AI agents are only as useful as the environment they can touch. Today you usually pick one of two bad options:
- Expose the machine - open a port, run a tunnel, hope the URL stays private.
- Upload the code - push the repo into a cloud sandbox that is never quite your machine.
Exeora is the third path. The CLI dials out to a gateway and holds a WebSocket open. Nothing ever dials in. Your files stay on the machine they already live on. Filesystem tools confine access to the project's registered roots. Commands and terminals run with the operating-system permissions of the account running Exeora; use command rules, approvals and a dedicated account or container to restrict that access.
flowchart TD
client["MCP client<br/><small>Claude · ChatGPT · Cursor</small>"]
subgraph cloud["exeora.dev · Cloudflare · or your own gateway"]
gateway["Gateway<br/><small>OAuth 2.1 · policy · audit</small>"]
relay["DeviceRelay"]
end
subgraph machine["your machine · laptop, server, VM, Pi"]
cli["Exeora CLI"]
repo[("your repository")]
end
subgraph instance["Exeora Cloud instance"]
cloudcli["Exeora CLI"]
clone[("a clone of the repository")]
end
client -->|"Streamable HTTP"| gateway
gateway --> relay
cli -.->|"outbound WebSocket only"| relay
cloudcli -.->|"outbound WebSocket only"| relay
relay -->|"tool.call"| cli
relay -->|"tool.call"| cloudcli
cli --> repo
cloudcli --> clone
- You run the CLI on the machine. It opens an outbound connection to Exeora. No inbound port, no VPN, no ngrok config. Add each directory you want to serve with
exeora project add. - You authorize a client once. OAuth 2.1 with PKCE. Each project can be its own URL and its own token, so blast radius is a fact about the path, not a promise the model is asked to keep.
- The agent works where the code already is - read, search, edit, run commands - under the policy you set. Revoke the machine from the dashboard and the socket closes immediately.
| Exeora | Tunnel (ngrok, Cloudflare Tunnel, …) | Cloud sandbox | |
|---|---|---|---|
| Where your code lives | The machine you ran it on | The machine you ran it on | A copy on their infrastructure |
| Inbound port | None | None, but a public URL is published | None |
| What is reachable | Project filesystem tools; commands under the executor's OS permissions | Whatever is listening on that port | A full shell in the copy |
| Per-project isolation | Separate OAuth resource and token | You build it | One sandbox per project |
| Authentication | OAuth 2.1, built in | Whatever your service does | The vendor's account |
| Your real toolchain and state | Yes | Yes | Reinstalled, never quite the same |
| Setup | Install, log in, connect | Run the tunnel, then secure it | Push your code |
- No inbound network path - outbound HTTPS is the only requirement. Home routers, corporate proxies and cloud VMs with no public address all work unconfigured.
- Your code stays where you put it - on a machine of yours, Exeora routes tool calls and does not store the repository. Exeora Cloud holds a clone only of a project you put there.
- A token per endpoint - a token minted for one project is refused at another. Ownership is checked in the database too.
- Filesystem paths stay in registered roots - filesystem tools reject
..and outward symlinks. Commands, terminals and configured upstream MCP servers retain their operating-system permissions. - Modes and command rules - read only, allow list, deny list, per-tool restrictions. Shell metacharacters are refused whenever a list is in force.
- Confirm before it runs - optional approval for edits and commands, in the conversation (MCP 2026-07-28) or on the terminal and dashboard.
- An audit log you can show someone - which tool ran, how it ended, how long it took. Never the arguments, never the output.
- Revoke and it stops - closing a machine kills the live socket that instant, not when a token expires.
- Bring your own client - Streamable HTTP, OAuth 2.1, PKCE, dynamic client registration. No plugin, no fork, no lock-in.
read_file · list_files · grep · edit_file · write_file · apply_patch · list_git_workspaces · create_workspace · attach_workspace · detach_workspace · remove_workspace · run_command · start_command · get_command_output · send_command_input · kill_command · list_skills
On the account URL, list_projects shows the available targets. When it returns more than one, every executor tool call names its project, so concurrent conversations do not move each other.
Both URLs also carry get_agent_prompt, which reaches no machine: it hands back Exeora's own coding-agent instructions, for a client that arrived without any. See the agent prompt.
Full reference: exeora.dev/docs/tools.
A project does not need a machine of yours switched on. Exeora Cloud is one more location a project can live in: an instance Exeora runs, with a clone of the repository, the CLI already connected, your tools installed by a script you write, and gh signed in as you. One instance per workspace; it sleeps a minute after it stops working and wakes on the next call, disk intact. Clients connect with the same URL and the same policy applies.
exeora project add owner/repo --on cloudSee Exeora Cloud.
Connect GitHub once and add a project by picking a repository, with no address and no token. Exeora clones, fetches and pushes with tokens that last an hour and reach that one repository. See connecting GitHub.
The dashboard shows what an agent changed: diffs, stage, commit, pull and push, and a web terminal on the same workspace, all under the project's policy. Exeora for Chrome puts that same screen in Chrome's side panel, next to the pull request you are reviewing. See Source Control and terminal.
Exeora can also start the MCP servers configured on your machine and re-publish their tools through its own MCP endpoint. List them in mcp.json next to Exeora's config.json, in the mcpServers shape other clients use; stdio and Streamable HTTP are supported. Upstream tools appear as mcp__server__tool, keep their schema and result, and follow the project's policy: a tool not marked read only is refused in a read-only project and confirmed where the project asks before changes.
See proxy other MCP servers for configuration, project servers and their trust setting, and limits.
No client plugin: anything that speaks MCP over Streamable HTTP with OAuth 2.1 connects. Step-by-step setup, checked against each client's own documentation, for:
Claude Code · Claude · ChatGPT · Cursor · VS Code · GitHub Copilot · Devin · Antigravity · Amp · Zed · OpenCode · Grok · Perplexity · Codex, Gemini CLI and Windsurf
To try one by hand, the MCP Inspector works too.
Claude Code and Cursor arrive knowing how to be a coding agent. claude.ai, ChatGPT and anything you wired up yourself do not, and it shows: they read files to find a symbol, overwrite a file they only half read, and treat a policy refusal as a problem to route around.
So Exeora ships a coding-agent prompt of its own, on four channels, because clients disagree about which they support:
instructionsin the MCP handshake. A short brief, arriving with nobody asking.- The
coding_agentprompt, for clients with an MCP prompt menu. - The
get_agent_prompttool, for everything else, and for a model that decides to read first. exeora prompt, for whatever is not an MCP client at all.
exeora prompt > AGENTS.md # or | pbcopy, or into a system prompt box
exeora prompt --account # the variant for the account URLIt is about Exeora rather than about your codebase, so keep your own AGENTS.md exactly as it is. Read it at exeora.dev/docs/agent-prompt.
The CLI is a single native binary:
# Linux
curl -fsSL https://exeora.dev/linux/install.sh | sh
# macOS
curl -fsSL https://exeora.dev/macos/install.sh | sh
# Windows PowerShell
irm https://exeora.dev/windows/install.ps1 | iexThe installer selects the release for your operating system and CPU, verifies its SHA-256 checksum,
and puts exeora on your PATH. The Linux binary needs glibc 2.31 or newer (Ubuntu 20.04 LTS,
22.04, 24.04, Debian 11 and later, current Fedora releases, and RHEL 9 and later). Later, one command updates it in place:
exeora upgradeThen add the printed URL to your client, for example:
claude mcp add --transport http exeora <the URL>Free while Pro is in development: 10 live machines, 25 projects, 2 Exeora Cloud instances and 24 hours of audit history, with no credit card. See plans and limits.
| Get started | Getting started · Connecting a client · Projects, locations and workspaces · Connecting GitHub |
| Use | Tools · The agent prompt · Proxy other MCP servers · Source Control and terminal · Chrome extension |
| Control | What a project allows · Security model · Plans and limits |
| Run | Exeora Cloud · Self-hosting (in this repo) |
| Reference | CLI reference · Troubleshooting |
| This repo | CONTRIBUTING.md · SECURITY.md |
| Path | What it is |
|---|---|
crates/exeora-cli |
Native Rust exeora binary and local tool executor |
crates/exeora-protocol-gen |
Rust types generated from the canonical Zod schemas |
packages/protocol |
Shared tool contract and relay wire format |
packages/design |
Design tokens |
apps/gateway |
Cloudflare Worker (OAuth, MCP, relay, API, static site) |
apps/web |
Landing, docs and dashboard sources |
apps/extension |
Exeora for Chrome, a shell that frames the dashboard's Workspace screen in the side panel |
e2e |
Playwright tests for the landing, docs and dashboard |
See CONTRIBUTING.md for local setup, tests and CLI releases.
Issues and pull requests are welcome. For vulnerabilities, email hello@exeora.dev - do not open a public issue.
If you modify Exeora and offer it as a network service, you must offer the corresponding source to the users of that service.