Visual Studio Live Share: Architecture and Trust Boundaries for Cross-Team Debugging

Your senior engineer needs to debug a failing integration with a contractor who cannot reach the internal repository or build cluster. Sending a ZIP archive ships stale code, and granting VPN access violates network policy. Visual Studio Live Share lets the host share a running debugging session over a signed join link while keeping source files on the host machine.

Use Live Share for ephemeral, host-controlled collaboration when source must not leave the host. Do not use it as a continuous integration substitute, a code-review gate, or a persistent shared development environment.

Requirements

• Zero-configuration co-editing and co-debugging across Windows, macOS, and Linux clients
• Localhost port forwarding so guests can reach services running on the host
• No requirement for identical SDKs, source control commits, or matching machine names
• Ad-hoc and persistent sessions across organizational boundaries
• Host retains final control over who joins and what they can do

Smallest suitable design

A Microsoft-hosted relay, Azure SignalR, brokers WebRTC peer connections between the host and guests. The host IDE runs the Live Share agent, a Node.js/Electron process that exposes a local language server protocol (LSP) proxy, file system virtualization, and a debug adapter shim. Guests connect through a signed join link. Only projected file buffers, debugger UI events, and terminal output cross the network. Source code is not persistently stored on Microsoft servers, and session encryption keys are ephemeral.

Trust and data boundaries

The host owns the session. Guests receive projections of open files, not direct file-system access. Authentication uses Azure AD accounts, including Microsoft accounts and GitHub identities. Session policies such as read-only mode, require-approval joining, and organization-only restrictions are enforced by the relay.

• Port forwarding exposes a localhost port to guests. Treat it as a temporary firewall hole. Do not forward database administration tools, secret managers, or other sensitive services.
• A guest debugger attaches to a host process. A malicious guest can inspect memory, set breakpoints, or modify variables. Share only with trusted collaborators.
• Session join links are bearer tokens. Anyone with the link can join until the host revokes it or ends the session. Enable require approval for sensitive codebases.

Operational checks

Before relying on a session, verify the agent and network path.

Health endpoint: GET /liveshare/health on the agent port, default 5000 to 5010, confirms the LSP proxy is ready.

Network egress check: run the following from a command prompt on the host during an active session:

netstat -an | findstr :443

Confirm established connections terminate only at *.liveshare.vsengsaas.visualstudio.com and *.service.signalr.net. This check requires no administrative privileges, but interpreting the output requires knowing which remote addresses belong to the Live Share service. Risk: a misread address list can miss an unintended connection.

Agent log: inspect %TEMP%\VSLiveShare\logs\agent.log on the host for the LSP proxy handshake and relay connection. Look for successful WebRTC candidate gathering or ICE relay entries.

Session details: in Visual Studio 2022, use the Live Share: Show Session Details command to view active port forwards, the guest list, and per-guest permissions.

Failure modes

• Relay outage: new sessions cannot start; existing peer-to-peer sessions usually continue.
• Host agent crash: the session ends for every guest.
• UDP blocked on the host firewall: traffic falls back to a TURN relay (a standardized intermediary for traffic blocked by firewalls), which adds latency.
• Guest network partition: automatic reconnect attempts within 30 seconds if the host remains reachable.
• Guest lacks the project SDK or language server: IntelliSense degrades, but text editing and debugging continue.
• More than five simultaneous guests or high-frequency terminal output: performance degrades. Use read-only observer mode for large audiences.

Conditions that change the design

• Air-gapped or fully on-premises environments: Live Share is not supported because there is no self-hosted relay.
• Strict data residency: consider the VS Code Live Share Extension with a self-hosted relay preview, which remains limited in scope.
• Large monorepos exceeding roughly 500,000 files: enable lightweight checkout and configure exclude patterns to restrict the projected file tree.
• Regulatory audit logging: export session metadata to Microsoft Purview for review.

Limitations and practical verification

Live Share shares runtime state, not verified artifacts. It is not a replacement for pull requests, code review, or CI pipelines. Proprietary or native-code extensions, such as some C++ IntelliSense components or Unity tools, may not project correctly to guests.

Verification steps:

1. Start a session in Visual Studio 2022 through View → Live Share.
2. Open %TEMP%\VSLiveShare\logs\agent.log and confirm the LSP proxy handshake and relay connection appear without fatal errors.
3. From a guest client, attempt to open a file outside the shared folder. The editor should return an access-denied result, confirming the file-system boundary.
4. Block UDP ports 3478 and 3479 on the host firewall, then check the agent log for ICE candidate type: relay entries to confirm the TURN fallback path.

Rollback: ending the Live Share session stops all sharing, disconnects guests, and closes forwarded ports. There is no persistent server state to roll back because code is not stored on the relay.