FAQ
Honest answers. What is real today, what is only planned, and the limits you should know about before you trust VESPR with anything that matters.
On this page
- What is real today, and what is not
- Who can see what
- The sandbox caveat
- Models and speed
- Everyday questions
- More known limits
What is real today, and what is not
| What | Status | Notes |
|---|---|---|
| Real VS Code in the browser, live shared editing with named cursors for people and agents | Built | One-time "trust this folder" prompt in the browser build. |
| Agent chat visible to the whole workspace, five permission modes, Approve / Deny cards where the first answer decides | Built | Anyone in the workspace can answer. No roles yet. |
| Authorship on hover and the authorship lens | Built | In the SDE. |
| Session replay | Built | In the SDE. The log grows without limit. |
| Code Map, as a panel and as an agent tool | Built | In the SDE. The app shell's View entry shows an example graph. |
| Run it: the agent starts the project and posts a preview link | Built | Asks the room first. Runs in the shared sandbox. |
| Run for Python from the app | Built | Off by default on shared servers. See the sandbox. |
| Inline suggestions, catch-up digest, token meter | Built | The meter counts tokens per agent and per person. |
| Git: commit, clone, fetch, push, log, blame by author | Built | Plain git over HTTP. |
| Branches, pull requests, reviews, issues, CI | Planned | |
| Open a GitHub repository in a workspace | Built | Pinned to one commit. Public repositories need no key. |
| Send workspace changes back to GitHub as a pull request | Planned | Designed, not built. |
| Skills, and the first-run question that sets them up | Built | Outside skills always ask the room. |
| Run commands on a server | Built | The runner program dials out to the VESPR server. |
| Run commands on a teammate's computer | Partial | Built and tested on Linux. The desktop wrapper is untested on Windows. |
| App shell for the whole team | Partial | A prototype. Chat, approvals, files, History and runs are live; some panels are not connected. |
| Desktop app and installers for Mac and Windows | Planned | A developer build exists and was tried on a Mac. There are no installers. |
| Accounts, sign-in and two-factor login | Planned | Today access is a login (token) issued by whoever runs the server. |
| Roles (owner, editor, viewer), private chats, a manager-only History | Planned | See who can see what. |
| A shared interactive terminal streamed to everyone | Planned | Run output is shared today; a live shared shell is not. |
| Public source repository | Planned | The license is AGPL-3.0-only. |
| Pricing, a free trial, payments | Planned | None of these exist today. |
Who can see what
Can I keep a file or a chat private inside a workspace?
No. A workspace is one shared document, and everyone who is connected to it sees all of it. One shared document cannot hide a file from a connected person. Concretely, anyone who holds a valid login for the server can join any workspace on it and read its files, its chat, its History and its session log, its uploads, and its git repository. There are no per-workspace or per-person permissions, no private chats and no private files today. Roles are Planned.
So the workspace is the boundary: put people who may see everything in it together, and keep anything else out of it. Two things make this more serious than it sounds:
- The session log records everything typed in the workspace. That includes anything sensitive someone pastes into a file or the chat.
- Agents read the workspace. What an agent reads is sent to the model provider (Nebius Token Factory) as part of its prompts. With no key, the scripted demo agent sends nothing anywhere.
The site's Security page states the same gaps from the website's side.
Can anyone approve an agent's action?
Yes. Anyone with a login to the server can answer any Approve / Deny card, change the agent mode, and read the History. Approvals are a way for a team to decide together and see who decided; they are not access control. Do not treat the card as a lock against someone who already has a login.
Where does my data live?
On the server you run: a snapshot per workspace, the session log and the uploads. What leaves it is what the agent sends to the model provider, the requests it makes to GitHub when you open a repository, and web searches if the operator has set a web-search key. Tokens are kept in files outside the source folder and are never logged by the server. They are sent in the URL's query string for WebSocket connections, which the server does not log.
The sandbox caveat
What is the problem?
When an agent runs a command, or someone presses Run in the app, the command runs in the sandbox: a throwaway folder inside the agent's own container. That sandbox is a convenience, not a wall. A command in it runs as the same operating-system user, in the same container, as the agent itself. So a command can read what the agent can read: the agent's environment, which holds its model key and its token for the workspace, and the list of tokens the agent needs for inline suggestions. The sandbox also shares the container's network, so a command can reach the internet.
This was found while building the Run button. It is not a leak that happens by itself: someone has to run a command. But anyone in a workspace can already get one run, by asking the agent to run a script and approving it. So:
- Only put people in a workspace whom you would trust with the agent's keys.
- On a shared or public server, leave Run off. The app's Run button is off unless the operator sets
MURMIO_HUMAN_RUNS=1on the agent, and the hosted demo deployment keeps it off. It is on in the local stacks, which are your own computer. - Use a key you can revoke, with a spending cap. The operator can cap the AI tokens used per 24 hours.
What is the fix?
Run commands in a separate sandbox container that holds no secrets, or run them as a different operating-system user that cannot read the agent's environment. Planned Neither is done. Until it is, treat the sandbox as shared with the agent.
Models and speed
Which models does it use?
NVIDIA Nemotron, through Nebius Token Factory. Nemotron 3 Super does everyday chat, edits and inline suggestions; Nemotron 3 Ultra does plan mode. The agent asks the account for its model list and picks from it. Without a key the agent runs a scripted demo mode, which is not a model, and says so in its messages.
How fast is it?
On 2026-10-28 we measured one small task ("fix the discount bug and run the tests again", Auto mode, a real model) three times. The first sign of work came after 0.5 to 0.9 seconds, the edit was visible in the file after 1.5 to 2.9 seconds, and the tests were green after 2.0 to 3.7 seconds. An inline suggestion took 0.62 to 0.68 seconds (the median of five in each run). That is one small task on one day, with the model running at Nebius; your numbers depend on your network, the task and the load on the model.
What can an agent read from an attachment?
Text, Word, PowerPoint (slides and speaker notes), Excel and CSV (rows), PDF, images, 3D models (size and triangle count), audio and video (duration). PDF reading is basic unless pdftotext is installed, and audio and video are described from their header only. When the agent could not read something, it is meant to say so rather than guess.
Everyday questions
Does "SDE" mean something else too?
Yes. The same letters are a common job title (Software Development Engineer) and have been used for other tools. Here it means smart development environment, and the full phrase comes first on a page.
Does it replace GitHub?
Not yet. You can commit the workspace to git, clone, fetch and push with any git client, read the log and blame by author, and open a GitHub repository in a workspace. Branches, pull requests, issues and CI are Planned, and so is sending changes back to GitHub.
Do my VS Code extensions and settings work?
The SDE is VS Code in the browser (Code - OSS), so the editor's own extensions, themes and settings are meant to work. A one-time "trust this folder" prompt appears, because the browser build cannot pre-accept it.
Can I try it without a key or Docker?
Yes. The demo stack needs Node.js, python3 and a shell, and nothing else.
Why does the code say murmio in places?
That was the project's earlier working name. Some command IDs, environment variables and folders still use it and will be renamed in a later release.
More known limits
- Live sync covers open files. In the SDE only the files someone has open are live-synced; others are snapshotted when first opened. If two people open a never-seen file at the same instant, its first version can be duplicated.
- The preview link is the only credential. Anyone who has the link can view the page while it runs, and the preview is served from the server's own address, so a malicious previewed page shares that origin. Do not put secrets in a previewed app. There is no hot reload through it.
- Tokens are compared with an ordinary lookup, not a constant-time one.
- A runner's display name is not verified. Anyone who registers a runner can choose the machine name that is shown, which is why the owner's name appears next to it.
- Uploads. Any valid login can read any workspace's uploads. Uploads are capped, checksummed and only ever served as downloads.
- Interface-only parts of the app shell: SSH hosts, the internet allowlist, GitHub commit and pull-request actions, the effort bar, and the Customize sheets.
- Where the agent's commands run. Besides the caveat above, the sandbox shares its container's network, and on a remote runner only read-only commands skip the approval card in Auto mode.