Tour of the app
A walk through what you see when you open VESPR, in the order you will meet it: the layout, agents, approvals, who wrote what, History, the Code Map, replay, running code, skills and GitHub.
On this page
- The layout
- Agents and the shared chat Built
- Approvals and permission modes Built
- Who wrote this, and why
- History Built
- Code Map
- Replay
- Running code
- Skills and the first-run question Built
- Open a GitHub repository Partial
- More in the SDE panel Built
- Keyboard shortcuts in the SDE
VESPR has two ways in. The SDE is full VS Code in the browser with the VESPR extension. The app shell is a team front door around it: agents, chat, History. The shell is a prototype in plain HTML and JavaScript. When it is connected to a workspace (live=1) the chat, approvals, files, History and runs are live. Not connected yet: SSH hosts, the internet allowlist, GitHub commit and pull-request actions, the effort bar, and the Customize sheets, which show example entries. Authorship hover, the working Code Map and the working replay live in the SDE; the shell's View menu entries for Code Map and Replay show example views for now. Each section below says which surface it is about.
The layout
Open the app shell (see Getting started). From the top:
- Search. A Search or jump to box. Ctrl+K (Cmd+K on a Mac) opens the same palette: agents, conversations and files.
- The layout switch: SDE | Chat | Split. SDE shows the code surface alone. Chat shows the conversation alone, full screen. Split shows both, and is the default.
- A connection pill. It reads Connecting, then Live followed by the workspace's name, for example Live (demo).
- History. A clock button that opens the History side panel.
Below the top bar:
- Left bar: the agents that are in the workspace (name, role, model, and a status dot that shows when one is working), then tabs for Files, Chats and Git. Click an agent to open its conversation; right-click it for a chat-only view.
- Centre: an editor with tabs, and a bottom panel with Terminal, Problems, Output and Ports. A VS Code tab opens the full SDE inside the shell; Built-in editor takes you back.
- Beside the editor: the team chat. Next to its input sit the agent mode, where commands run (the sandbox, by default), the model, and an effort bar that is not connected yet and does not change anything.
Agents and the shared chat Built
Mention an agent to talk to it: @coder run the tests. An agent only answers messages that mention it. What you type and what the agent answers is visible to the whole workspace; there are no private chats today (see the FAQ).
- Conversations. A message can belong to a named thread. Without one it goes to
main. - Select to ask. Select text in a file, the chat or the terminal output and press the Ask button that appears. The agent gets exactly that text and where it came from.
- Attachments. Attach a Word, PowerPoint or Excel file, a CSV, a PDF, an image, a 3D model, audio or video. The agent reads what it can (text, slides and speaker notes, sheet rows, 3D size and triangle count, media duration) and says plainly what it could not read. Uploads are size-capped, checksummed and only ever served as downloads, never as pages. PDF reading is basic unless
pdftotextis installed, and audio and video are described by their header only. - The agent's work is visible. Its steps stream into the chat as it works, and when it edits a file it has its own named cursor in it.
Approvals and permission modes Built
Before an agent changes a file or runs a command, the workspace's mode decides whether it may go ahead alone or must ask. When it must ask, an Approve / Deny card appears in the chat for everyone. The first answer decides. A later click does nothing, and the card shows who answered. A card nobody answers expires after five minutes and the agent does not go ahead.
| Mode | What the agent may do on its own |
|---|---|
| Manual | Read. It asks before every edit and every command. This is the default. |
| Accept edits | Read and edit. Commands ask. |
| Auto | Read and edit. Commands that look safe (running a script or the tests, linters, read-only shell commands) go through; risky ones ask; dangerous ones are refused. |
| Plan | Read only. It writes a plan in chat and changes nothing until a person approves the plan. |
| Bypass | Everything goes through with no prompts. Intended for the sandbox only. It never applies on someone else's computer: there it falls back to Auto. |
The mode is part of the shared workspace, so everyone sees it, and anyone in the workspace can change it. That is a known limit: there are no per-person permissions yet (Planned). More in Concepts.
One rule holds in every mode: if someone else is working in a file, the agent asks before editing it (see claims).
Who wrote this, and why
In the SDE Built
Every character records its author: the person or agent, and for an agent also the model and the chat message that caused it. Hover any line and a popup reads, in the form: coder (agent, model …) wrote this at 07:53 AM. Because <person> asked: <their message>. The Authorship button in the VESPR panel (or Ctrl+Alt+M, then L) turns on a lens that tints the text by author. Authorship survives merges and shows up again in replay and in the Code Map.
In the app shell Partial
When an agent edits a file the shell shows the change as it is typed: the old line turns red, the new one is typed in green with the agent's name. Both colors stay until your next message. A small marker on the tab shows the file was changed by the agent.
History Built
The clock button opens a side panel titled History: who did what, and when. It lists edits, runs, approvals and changes to settings, newest first: who (a person, an agent or the system), what they did, to what, and for runs the exit code and how long it took. Filter by All, Edits, Runs, Approvals, Access or Decisions, search by person, action or file, and Export as CSV to get the whole list as vespr-history.csv.
History is built from the shared workspace itself, so it needs no extra storage. That also means there is no retention policy and no manager-only view yet: everyone in the workspace can see it (Planned: role checks).
Code Map
In the SDE Built
Press Ctrl+Alt+M, release, then M (Cmd+Alt+M on a Mac), or run VESPR: Show code map from the command palette. You get a live map of the workspace: each file is a dot, imports are lines, and by default the dots are colored by who wrote them. A teal ring marks a file that is mostly agent-written, and a hollow centre marks an entry point. The header counts files, lines, symbols and imports and the share written by agents. Search for a file or symbol, click a file for its symbols, imports and authors, double-click it to open it, drag to rearrange and scroll to zoom.
The map reads symbols in JavaScript, TypeScript, Python, Go and Rust files, and import links in JavaScript, TypeScript, Python and HTML files. It is static analysis of the text: dynamic imports, string lookups and generated code are invisible to it.
The agent can ask the same map through a code_map tool before it explores file by file: overview, file:<path>, impact:<path> (everything that depends on a file, to use before changing a shared one) and symbol:<name>.
In the app shell Partial
View, then Code Map shows an example graph, not your workspace.
Replay
In the SDE Built
The server records every change to the shared document and every presence change in a log. Replay (the button in the VESPR panel, Ctrl+Alt+M then R, or VESPR: Replay this session) rebuilds any moment from it and opens a tab with a Play button, a speed menu and a scrub bar. Drag back and the files show their text tinted by author, with the collaborators' cursors, while the chat and the approvals of that moment scroll alongside. The log grows without limit (a known limit).
In the app shell Partial
View, then Replay shows an example scrub bar, not your session.
Running code
Run for Python Built
A Run button in the tab bar and the Terminal panel (Ctrl+Enter, Cmd+Enter on a Mac) runs the open Python file as python3 <file>, or the tests as python3 -m unittest discover -v. The output appears in the Terminal panel for everyone in the workspace, errors appear in Problems with the failing line marked in the editor, and a failed run offers Ask coder to fix.
The request is a small entry in the shared workspace that carries a kind (a file or the tests) and a file name, never a command line, and the agent checks that it is a .py file in the workspace before it runs it. A person cannot use it to start anything else, and it cannot start a run on a teammate's computer: those still need an approval through the agent.
Run executes workspace code inside the agent's own container, next to the agent's secrets. So it is off unless the operator sets MURMIO_HUMAN_RUNS=1 on the agent. It is on in the local Docker stack and the demo stack (your own computer) and off on the hosted demo deployment and the other deploy files. When it is off the button is greyed and says Running from the app is off in this workspace. Ask @coder to run it. Why this matters: the sandbox caveat.
Run it: preview the project Built
Ask @coder start the website (or "run the project", "preview the app"). The agent works out the stack from the workspace files, asks the room to approve (it starts a program that listens on a port), installs, starts it in the background and posts a preview link in the chat that everyone can open. If it does not come up it reads the process log and tries to fix the cause. It recognizes Node projects (Vite, Next.js, Create React App, Express and other servers), Python (Flask, FastAPI, Django, or a folder with index.html), static sites, Makefile targets, Go and Rust.
Limits: the link is the only credential, so anyone who has it can view the page while the process runs; a process lives 30 minutes and a workspace can have three; there is no hot reload through the preview; Next.js previews can look incomplete; and it runs in the shared sandbox, not on a teammate's computer.
Skills and the first-run question Built
A skill is a plain SKILL.md instruction file for one kind of task. Skills live in the workspace under .vespr/skills/, so everyone sees who added them. Before an agent says it cannot do something, it searches the installed skills, the library and connected GitHub repositories.
The first time you open a workspace the app asks what it is for: vibe coding (describe it, build it in small steps, see it run, fix it), websites and web apps, UI and visual design, backend and APIs, data and analysis, or docs and writing. You can pick several. The answer sets up skills for those fields:
- Bundled skills ship with VESPR and are copied into
.vespr/skills/at once. They are ours and need no approval. - Skills from public GitHub repositories (for the vibe, web and design fields) are fetched only after the room approves one card that lists exactly what will come and under which license. Each is pinned to a commit, and only its
SKILL.mdis fetched, not the scripts and data files next to it. - Something else. Type what the workspace is for in your own words (one line, up to 200 characters). The agent searches GitHub for matching skills without calling a model. It keeps only repositories that are not archived or forks, carry an open license (MIT, Apache-2.0, BSD, ISC, Unlicense or CC0), have at least 20 stars and were updated in the last 18 months or so, and it offers at most three on one approval card.
- Installing a skill from outside always asks the room, in every mode.
You can answer "nothing", and you can ask again later from View, then Skills for your field…. An agent that does not offer this feature never publishes its list of fields, so the app does not ask.
Open a GitHub repository Partial
View, then Open a GitHub repo…. Enter owner/repo or a link (a branch or folder link works). The agent:
- reads the default branch and the license, and pins the branch to one commit;
- downloads that commit's archive (only
api.github.comandcodeload.github.comare allowed, with a size cap); - writes the text files into the shared workspace. It skips and counts files over 200 KB, binary files, dependency and build folders such as
node_modulesanddist, names the workspace cannot hold, and anything past 400 files or 2 MB. A file that already exists is never overwritten; - keeps the starting point (owner, repository, branch, commit, license, and the git hash of every imported file) in the workspace settings, and says in chat what it opened and what it skipped.
Public repositories need no key. A private one works only if the operator gives the agent a GITHUB_TOKEN; it is sent to api.github.com only and never shown. Sending your changes back as a pull request is Planned: it is designed (compare against the pinned starting point, one approval card listing the files and the target branch, never a force-push) but not built, and the shell's GitHub commit and pull-request buttons are not connected yet.
More in the SDE panel Built
- Who is here / Follow. Everyone, people and agents, has a named cursor. Pick a collaborator or an agent to follow their view.
- Catch up. Be away for a while, press Catch up (or accept the welcome-back prompt) and the agent lists what happened: chat, approvals, commands, mode changes, and who edited which file.
- Commit. Snapshots the workspace to git with a message written from who did what and the request behind it. You can also clone, fetch and push with any git client; a push is imported back into the live workspace as edits by the person who pushed.
- Runs on. Choose where commands run: the sandbox, a connected server, or a teammate's computer (it asks its owner first). See runners.
- Inline suggestions. Grey ghost text as you type that also knows what teammates and agents just did.
Keyboard shortcuts in the SDE
Every action is a named command. Default keys use a chord: press Ctrl+Alt+M (Cmd+Alt+M on a Mac), release, then one letter. You can rebind any of them by searching "VESPR" in Keyboard Shortcuts.
| Then press | Command ID | What it does |
|---|---|---|
| c | murmio.chat | Open the team chat |
| m | murmio.codemap | Show the Code Map |
| a / d | murmio.approve / murmio.deny | Approve or deny the newest pending agent request |
| u | murmio.runIt | Ask the agent to start the project and post a preview link |
| k | murmio.askAgent | Ask the agent (the box is pre-filled with @coder ) |
| t | murmio.say | Say something in the team chat |
| s | murmio.mode | Pick the agent mode |
| w | murmio.catchUp | Catch me up on what happened while I was away |
| r | murmio.replay | Replay this session |
| l | murmio.lens | Toggle the authorship lens |
| g | murmio.commit | Commit the workspace to git |
| p | murmio.people | Who is here |
| f | murmio.follow | Follow a collaborator |
The command IDs are the stable part, so they also work from keybindings.json with arguments and from any macro tool that can press keys. A browser may keep some Ctrl+Alt combinations for itself; if a chord does nothing, rebind it. The approve and deny path and the key table are covered by tests; the chords have not been tried in every browser.