Remote debugging
“Find why the service fails on staging using the logs and dependencies already there.”
Work against the real environment instead of recreating it in a sandbox.
What becomes possible
The real machine, not a copy of it
Give an agent the environment that already has the code, dependencies, credentials, and state it needs to finish the work
Real repositories
“Review this repository, fix the type errors, and run its test suite.”
Give a web-based AI access without cloning or uploading the repository.
Every machine
“Update the API on my build VM, then check the deployment from my Raspberry Pi.”
Use the same MCP client across laptops, servers, VMs, and edge devices.
Controlled execution
“Read everything, but ask before edits and only run the commands I allow.”
Set the boundary per project, audit every call, and revoke access immediately.
How it works
From machine to MCP in three steps
No tunnel configuration, no repository upload, and no plugin for each AI client
- 1
Connect the machine
Install one native binary and run exeora connect. It signs in and opens an outbound connection, even behind NAT or a corporate firewall
exeora connect - 2
Add the project
Register the directory you want to serve, or a GitHub repository. Exeora prints an MCP URL scoped to that project, not a shell endpoint for the whole machine
exeora project add - 3
Paste the URL into your AI
Authorize it once, then read, search, edit, and run commands under the policy you choose. Revoke it from the dashboard whenever you want
https://exeora.dev/p/<project>/mcp
No machine to connect? Add a repository to Exeora Cloud from the dashboard and skip the first step.
The platform
Everything around the tool calls
Machines are one place a project can live. Exeora also runs it for you, clones it from GitHub, and shows you what your agents changed
Exeora Cloud
No machine switched on? It still works.
Put a project on an instance Exeora runs: a clone of the repository with the CLI already connected, your tools installed by a script you write, and gh signed in as you. It sleeps when idle and wakes on the next call, with its disk kept.
$ exeora project add owner/repo --on cloud- ✓ One instance per workspace
- ✓ Same URL, same policy as your machines
- ✓ 2 instances on the free plan
GitHub, without tokens to paste
Pick a repository instead of a directory. Exeora clones, fetches and pushes with tokens that last an hour and reach that one repository.
Review what the agent did
Source Control in the dashboard: the diff of every change, then stage, commit, pull and push without leaving the browser.
A terminal on any workspace
Open a shell on the machine or instance a workspace lives on, from the dashboard, under the same project policy.
Right next to the pull request
Exeora for Chrome puts that workspace in the side panel, beside whatever tab you are reviewing.
Add to Chrome ↗Your other MCP servers, once
List them in mcp.json on the machine. Exeora publishes their tools through the same URL, under the same project policy.
Instructions every client follows
One agent prompt and your project's Agent Skills, delivered to every client the same way, so Claude and Cursor work the same.
Guarantees
Built so the dangerous parts are small
One outbound connection, one resource per project, rules you can tighten, and a log that records what happened without recording what was in it
No inbound path
Nothing listens on the machine. The CLI opens an outbound connection and holds it, so 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, files are read, searched and edited where they already are, and only the result of a call crosses the wire. Nothing copies a project between the places it lives, and Exeora Cloud holds a clone only of what you put there
Blast radius you choose
Every URL is its own OAuth resource, so a token for one project is refused at another. Paths are resolved through realpath before anything touches disk - `..` and outward symlinks are rejected
Policy you can tighten
Read only, allow list, deny list, per-tool restrictions, and optional approval before edits and commands. Shell metacharacters are refused whenever a list is in force
Audit without leaking
Which tool ran, how it ended, how long it took, and which client asked. Never the arguments, never the output - a log you can show someone
Revoke and it stops
Closing a machine kills the live socket that instant, not when a token expires. The whole stack is open source under AGPL-3.0 - audit it, fork it, contribute
17 tools, confined to the project - full tool reference
Why Exeora
A local MCP works where the client runs. Exeora works where your project runs.
Reach a real development environment from any compatible AI client without turning that environment into a public endpoint
Where it runs
- Exeora
- Any machine of yours, or an instance on Exeora Cloud
- Local MCP server
- The same computer as the client
- Cloud sandbox
- A vendor-hosted copy
Web clients such as ChatGPT
- Exeora
- Connect directly over authenticated HTTP
- Local MCP server
- Needs a separate remote bridge
- Cloud sandbox
- Built into the vendor
Authorization boundary
- Exeora
- One OAuth resource per project
- Local MCP server
- Usually one user-level configuration
- Cloud sandbox
- One vendor account
Real toolchain and state
- Exeora
- Yes, in the location the call lands on
- Local MCP server
- Yes, on the client machine
- Cloud sandbox
- Reinstalled in the copy
Policies and approvals
- Exeora
- Per project, enforced at both ends
- Local MCP server
- Depends on the MCP server
- Cloud sandbox
- Depends on the vendor
Central audit and revocation
- Exeora
- Built in
- Local MCP server
- Usually local
- Cloud sandbox
- Vendor-specific
Setup
- Exeora
- Connect a machine, or pick a repository for Exeora Cloud
- Local MCP server
- Install in every client environment
- Cloud sandbox
- Upload or import the repository
Source
- Exeora
- Full stack, AGPL-3.0
- Local MCP server
- Varies by server
- Cloud sandbox
- Usually closed
What you are agreeing to
An agent you connect can run anything inside that project
A new project allows everything until you narrow it. From the dashboard you can set it to read only, name the commands it may run, refuse specific ones in any mode, choose which tools exist, and ask to confirm every change before it happens. Paths stay confined to the project root either way, but that confinement is not a sandbox: a command that runs still runs as you, with your environment and your network.
An allow list with shell turned on is only a suggestion. Confirmation only reaches a person who is there: in the conversation on MCP 2026-07-28, and otherwise on the machine's terminal or in the dashboard. Revoking a machine from the dashboard closes its connection immediately, so that is the stop button.
The full model is in what a project allows. The source is public on GitHub, so you can audit every line.
FAQ
The questions worth asking first
What Exeora can see, what it can control, and how to cut access
Can you see my code?
Not on a machine of yours. The gateway routes tool calls and returns their results; it never receives a copy of your repository. What does cross the wire is whatever a tool returns, for example the lines a grep matched, and none of that is stored. The audit log records the tool name, the outcome and the duration, never arguments or output. Exeora Cloud is the exception, and one you choose: a project you put there is cloned onto an instance Exeora runs.
What happens when the machine goes away?
The connection drops and calls that land on that machine fail immediately with LOCAL_EXECUTOR_OFFLINE. Nothing is queued, by design: every call also carries an absolute deadline that the CLI rechecks on arrival, so a command asked for hours ago cannot run when the machine wakes up. A project that also lives on another machine or on Exeora Cloud stays reachable through its workspaces there.
Can I limit which commands run?
Yes. From the dashboard you can set a project to read only, name the commands it may run, refuse specific ones in any mode, choose which tools exist, and ask to confirm every change before it happens. A project may also carry an exeora.toml that can only narrow those rules, never widen them. See what a project allows.
Does this work behind a corporate firewall?
If the machine can make outbound HTTPS requests, yes. The CLI opens the connection outward and keeps it, so there is no inbound rule to request, no port to forward and no VPN to join.
How do I revoke access?
Revoke the machine from the dashboard. That closes its live socket at once and stops it serving anything, rather than waiting for a token to expire. Removing a project takes its MCP URL out of service the same way.
Is Exeora open source?
Yes. The full stack - CLI, gateway, dashboard and docs - is public on GitHub under the AGPL-3.0. You can read every line, audit the security model, open issues and send pull requests. The hosted product at exeora.dev runs that same code.
What does Google Sign-In access?
Google Sign-In is optional. Exeora uses only your verified email address, name, and profile photo to authenticate you. It does not request Gmail, Drive, Calendar, contacts, or other Google services, and never stores Google access or refresh tokens. See the privacy policy.
Free while Pro is in development
Connect your first machine
One native binary, one browser sign-in, and an MCP URL for the client you already use. No credit card and no model subscription from us.
- 10 live machines
- 25 projects
- 2 Cloud instances
- 24 hours of audit history
Exeora runs on a desktop. Choose the macOS, Linux or Windows tab for the machine where you will install it.
curl -fsSL https://exeora.dev/macos/install.sh | shexeora connectexeora project addmacOS, Linux and Windows · Or start on Exeora Cloud · Source · Releases