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
- 2
Add the project
Register the directory you want to serve. Exeora prints an MCP URL scoped to that project, not a shell endpoint for the whole machine
- 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
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 connected machine
- 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, on the target machine
- 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 the machine and add a project
- 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
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 never leaves
Exeora routes tool calls; it does not store the repository. Files are read, searched and edited where they already are, and only the result of a call crosses the wire
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
Fifteen tools, one project directory - full tool reference
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?
No. 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.
What happens when the machine goes away?
The connection drops and calls to that project 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.
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
- 90 days 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 · Self-hostable · Releases