# Visual Studio Live Share: what the microsoft/live-share repository actually contains

> The microsoft/live-share repository is the feedback and documentation hub for Visual Studio Live Share, not the extension itself. Here is what it documents, where the install instructions actually live, and who should stay away.

**microsoft/live-share** — Real-time collaborative development from the comfort of your favorite tools

- Repository: https://github.com/microsoft/live-share
- Website: http://aka.ms/vsls
- Stars: 2,386 · Forks: 260
- Language: Unknown
- License: CC-BY-4.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-live-share

## What the microsoft/live-share repository is, and what it is not

The name is misleading if you arrive expecting an implementation. The README opens as "Visual Studio Live Share Feedback" and the body is a set of links: quickstarts, how-tos, reference pages, resources. There is no source tree for the collaboration engine, no build instructions, no package manifest. The top-level entries are .editorconfig, .github/, .gitignore, .vscode/, CONTRIBUTING.md, LICENSE, LICENSE-CODE, README.md, SECURITY.md and ThirdPartyNotices. That is the layout of a documentation and issue-tracking repository, and the contributing section confirms it: up-vote a feature request, search existing bugs, or report a problem through CONTRIBUTING.md.

The product itself is described in the README as enabling developers "to achieve greater confidence at speed by streamlining collaboration in real-time during development", with a link to aka.ms/vsls. So the repository is the front door, not the house. If you are evaluating Live Share as a tool, you are evaluating a Microsoft-hosted service with editor extensions, and this repository is where you file feedback about it. If you are evaluating it as an open source project to fork or self-host, this is the wrong artifact entirely, and the README never claims otherwise.

That distinction matters for procurement. Someone reading the repository name, the CC-BY-4.0 license and the Microsoft organisation may conclude they can run the whole thing internally. Nothing in the README supports that reading.

## Who Live Share is for: pair programming without the screen-share tax

The problem the README frames is real-time collaboration during development. The two quickstarts are "Share your first project" and "Join your first collaboration session", and the how-tos are split by editor: collaborate using Visual Studio Code, collaborate using Visual Studio. The topics list on the repository adds collaboration, pair-programming, visual-studio and visual-studio-code.

That is a narrower audience than "anyone who collaborates". The intended user is a developer working in one of Microsoft's two editors who wants a second person inside the same project. The reference links hint at the friction points that follow: connectivity requirements, security features, Linux install details, language and platform support, extension support, common use cases, troubleshooting. A tool that needs a page for connectivity requirements and another for extension support is not frictionless, and the README does not pretend it is.

The common use cases page is linked but not reproduced, so the README does not enumerate them. What can be said from the structure is that the documented scenarios are editor-centric: share a project, join a session, and then whatever the language and extension support pages permit.

## How a session works, as far as the documentation describes it

The README does not include an architecture diagram or a protocol description. What it gives is a set of reference topics that define the mechanism at the level a user needs: connectivity requirements, security features, and a page on connection mode. The presence of a dedicated connectivity page implies sessions are not purely local network traffic; the guest and host must satisfy some network condition, and the connection mode reference is where that is explained.

There is also a separate page for extension support, which tells you the collaboration surface is not limited to text buffers. Extensions can participate, and the README links to the VS Live Share Extension API published on npm as vsls, plus a samples organisation at github.com/vsls-contrib. That is the extension path: an editor extension author consumes the vsls package, and the samples repository shows how.

Beyond that, the README is silent on data flow. It does not state where session data is relayed, what is stored, or how long anything persists. The security features page is linked under Reference, and that is the correct place to look, because the README itself does not answer it. Anyone who needs to know whether source code transits a Microsoft relay should read that page before installing, not after.

## Installing Live Share and joining a first session

The repository gives no install commands. Installation is handled by the editor's extension marketplace, and the README routes you to the how-to for your editor: aka.ms/vsls-docs/vscode for Visual Studio Code and aka.ms/vsls-docs/vs for Visual Studio. Linux users get a dedicated page at aka.ms/vsls-linux, which suggests the Linux path has extra steps that the general how-to does not cover.

Because the README does not publish a CLI, a package name for the editor extension, or a version, there is nothing to copy here that would be accurate. The honest instruction is: open the how-to link for your editor and follow it. The one concrete artifact the README does name is the extension API package, which is for extension authors rather than end users:

```bash
npm install vsls
```

That installs the VS Live Share Extension API, the package the README links on npm. It is not what you install to join a session; it is what you depend on if you are writing an extension that participates in one. The samples live at github.com/vsls-contrib, which the README lists under Resources.

For a first real use, the sequence the README implies is: install through your editor, then follow "Share your first project" at aka.ms/vsls-docs/share, then have the other person follow "Join your first collaboration session" at aka.ms/vsls-docs/join. Before either step, check the connectivity requirements page, because that is where the documented network conditions live. If you are on Linux, read aka.ms/vsls-linux first rather than discovering the difference mid-session.

## Where Live Share is the wrong tool

The clearest boundary is the editor. The how-tos cover Visual Studio Code and Visual Studio. The search data around this project includes people asking how to use Live Share in Cursor, and the README offers no answer: Cursor is not named anywhere in the README. Treat that as unresolved rather than supported. If your team has standardised on a non-Microsoft editor, this repository gives you no basis to assume the extension works there.

The second boundary is deployment. Nothing in the README describes a self-hosted server, an on-premises relay, or an air-gapped configuration. The connectivity requirements and connection mode pages exist precisely because connectivity is constrained, and the security features page is a separate document. An organisation that cannot send session traffic outside its network has no documented path here.

The third boundary is scope. This is a feedback repository. If your question is "what does the relay do with my code", the README will not tell you, and neither will the issue tracker in any authoritative way. That answer belongs to the security features page and the product license terms, both linked but not reproduced. A repository whose contribution guide is about filing bug reports is not a specification.

## Alternatives and the actual difference in approach

The obvious alternative is plain screen sharing combined with a shared repository. The difference is not quality, it is where the state lives. With a screen share, the guest sees pixels and cannot type into the host's buffer, run a command in the host's terminal, or follow the host's debugger. Live Share, as the README frames it, puts the guest inside the project: the quickstart is "Join your first collaboration session", not "watch a stream", and there is a dedicated page for extension support, which only makes sense if guests interact with tooling rather than watch it.

A second alternative is committing to a branch and letting the other person pull. That is asynchronous and needs no connectivity page, no connection mode, and no security features document, because nothing leaves your infrastructure beyond the repository you already share. The trade-off is latency of feedback. Live Share is aimed at the case where waiting for a push and a pull is the thing you are trying to avoid.

The third alternative, for editor-extension authors specifically, is to build collaboration into your own extension. The README points you at the vsls npm package and the vsls-contrib samples, which is the supported way to do that. The difference from adopting Live Share as a user is that you are then responsible for the collaboration behaviour your extension exposes, and the platform support and extension support pages become constraints on your design rather than answers.

## Maintenance, licensing and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-03. There are no releases in the README, which fits a feedback and documentation repository: there is no versioned artifact to ship. Documentation changes land as commits, and the links point at aka.ms short URLs, so the actual content lives outside the repository and can change without a commit here.

That is the maintenance cost worth naming. Your upgrade path is not a changelog in this repository. It is the editor extension updating on its own schedule, plus whatever the aka.ms pages say when you next open them. If you are pinning versions for a controlled environment, the README gives you no version numbers to pin.

On licensing: the README states that by downloading and using Visual Studio Live Share you agree to the product license terms at aka.ms/vsls-license and the Microsoft privacy statement. The CC-BY-4.0 license in the repository covers the documentation, and the README separately notes that documentation code samples are under the MIT License. The LICENSE-CODE file at the top level exists for that purpose. The practical reading is that the permissive licenses apply to what is in this repository, and the product itself is governed by separate terms. That is a distinction to check with whoever handles your procurement, not something to infer from the repository's own license field.

## Conclusion

Adopt Live Share if your team already works inside Visual Studio or Visual Studio Code and you want a guest to edit the host's files and share a debug session without pushing a branch. Do not adopt it if you need a self-hosted relay, if you use Cursor or another VS Code fork, or if you expect this repository to give you source code to audit. Verify first that your editor is on the platform support page, that the guest's network allows the required connectivity mode, and that the language you are pairing on appears in the language and platform support list. The repository itself is a pointer, so read aka.ms/vsls-docs/share before you promise anyone a session.

## FAQ

### How do I install Live Share?

The README does not publish install commands. It routes you to the how-to for your editor: aka.ms/vsls-docs/vscode for Visual Studio Code and aka.ms/vsls-docs/vs for Visual Studio, with a separate page at aka.ms/vsls-linux for Linux install details.

### How do I use Live Share in VS Code?

The README lists a how-to titled "Collaborate using Visual Studio Code" at aka.ms/vsls-docs/vscode, and a quickstart for sharing your first project at aka.ms/vsls-docs/share. The repository does not reproduce the steps.

### How do I use Live Share in Visual Studio 2022?

The README groups Visual Studio under a single how-to at aka.ms/vsls-docs/vs and does not break the instructions down by year or version. Nothing in the README distinguishes 2022 from any other release.

### Does Live Share work in Cursor?

The README only documents Visual Studio Code and Visual Studio. Cursor is not named anywhere in the README, so there is no documented basis for expecting the extension to work there.

## Sources

- [Issues](https://github.com/microsoft/live-share/issues)
- [License: CC-BY-4.0](https://github.com/microsoft/live-share/blob/main/LICENSE)
- [microsoft/live-share on GitHub](https://github.com/microsoft/live-share)
- [Project website](http://aka.ms/vsls)
- [README](https://github.com/microsoft/live-share/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-live-share