microsoft/vscode: what the Code - OSS repository actually is, and how to build it from source

Code - OSS is a source repository, not the editor you download

The README opens by naming the repository Code - OSS and describing it as the place where Microsoft develops the Visual Studio Code product together with the community. That sentence carries the whole distinction. The repository is the upstream source; Visual Studio Code is described as a distribution of it with Microsoft-specific customizations, released under a traditional Microsoft product license. So there are two artefacts with two licences. The code here is MIT. The binary most people install from code.visualstudio.com is not.

Who is this for, then? Three groups. Engineers who want to read how the editor, the extension host, or the language-feature extensions are implemented. Teams that need to patch a bundled extension, since the extensions folder holds grammars, snippets, and the language-features packages. And anyone building a separate distribution on top of the MIT source, which is the case the licence actually permits.

It is not for someone who wants a code editor today. The README does not present the repository as an installation channel at all; it points readers at the download page and at the Insiders build for daily releases. Treat the repository as a build input, not a product.

How the TypeScript monorepo is put together

The top-level layout shows a single repository holding several distinct things. src/ is the client. extensions/ holds the bundled extensions, and the README explains the naming convention: extensions that provide rich language support such as inline suggestions or Go to Definition carry the suffix language-features, so json gives colouring while json-language-features gives the deeper support. cli/, remote/, and build/ cover the command-line entry point, the remote work, and the build tooling. test/ and scripts/ hold the test runners.

The build is driven from the root package.json, which is marked private and named code-oss-dev. Scripts are chained: compile runs compile-client and compile-copilot, and compile-client delegates to gulp compile. There is a typecheck-client script that runs tsc against src/tsconfig.json with --noEmit, and a check-cyclic-dependencies script that inspects the out directory. That last one tells you something about the architecture: this is a large TypeScript graph where import cycles are a real enough risk to warrant a dedicated check.

The repository also ships a dev container. The README says the Docker image or Codespace should have at least 4 cores and 6 GB of RAM, with 8 GB recommended, to run a full build. That is the honest cost of the checkout, and it is the number to plan around.

Building Code - OSS from source in a dev container

The README gives two container routes. For Dev Containers, it names the command Dev Containers: Clone Repository in Container Volume..., which creates a Docker volume for better disk I/O on macOS and Windows. For Codespaces, it says to install the GitHub Codespaces extension and use Codespaces: Create New Codespace. Both avoid a local toolchain setup.

If you already have VS Code and Docker, the README offers a redirect link that triggers the same flow. The URL form is worth knowing because it is copyable:

https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/microsoft/vscode

Once the container is up, the root package.json is the entry point for building. The scripts listed there are the ones to use, and compile is the aggregate target:

npm install
npm run compile

The preinstall and postinstall hooks in package.json run build/npm/preinstall.ts and build/npm/postinstall.ts, so dependency setup is not a plain npm install. Expect those to do work before anything compiles. After compile finishes, the output lands in out/, which is the directory the cyclic-dependency check inspects.

For a faster loop there is build-fast, and watch runs a parallel npm-run-all2 task set. The README does not document a rollback path for a failed build, so plan on removing out/ and rebuilding rather than expecting an undo command.

The licence boundary is the real limitation

The most consequential constraint is not technical. The repository is MIT, and the README states that plainly. But the README also states that Visual Studio Code is a distribution of this repository with Microsoft-specific customizations released under a traditional Microsoft product license. If you fork the source and ship a binary, you are shipping Code - OSS under MIT, not Visual Studio Code. The branding, the Marketplace access, and the product licence do not travel with the source.

There is a second boundary that shows up in the file listing rather than the prose. The repository contains cgmanifest.json, cglicenses.json, and ThirdPartyNotices.txt. A project this size accumulates dependencies with their own terms, and the manifest files exist to track them. Anyone redistributing a build should read those rather than assume the single MIT line at the top covers every file. This is not legal advice; it is a pointer to the files that answer the question.

The third limitation is scale. A fresh checkout plus a full build is a heavy operation against the 4-core, 6 GB floor the README sets. If your goal is to tweak a theme or add a keybinding, cloning this repository is the wrong tool. Install a released build and write an extension instead.

Code - OSS against a lighter editor such as Vim or Neovim

The obvious alternative for someone who wants a terminal editor is Vim or Neovim, and the difference is architectural rather than cosmetic. Neovim runs as a single process with a built-in Lua runtime and a client-server model, so a plugin is a script the editor loads. Code - OSS runs an Electron shell with a separate extension host process, and its bundled extensions are TypeScript packages compiled as part of the repository build. That separation is why an extension cannot block the UI the way an in-process plugin can, and it is also why the build is measured in cores and gigabytes rather than a single binary.

The trade-off runs both ways. Neovim starts in milliseconds and installs from a package manager; Code - OSS needs a container or a toolchain and a full compile. Neovim's plugin ecosystem is text-oriented; the language-features extensions here ship inline suggestions and Go to Definition out of the box. Pick based on whether you want an editor you configure in a file or an editor you build from a monorepo.

Maintenance cadence and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-26. Releases are frequent: 1.133.0 on 2026-08-12, 1.134.0 on 2026-08-19, and 1.135.0 on 2026-08-26, roughly weekly in that window. The README describes the product as updated monthly with new features and bug fixes, which matches the tagged release rhythm rather than the push rhythm. The root package.json carries version 1.139.0, ahead of the newest tagged release, which is normal for a main branch that has moved on since the last tag.

For a downstream fork, that cadence is the upgrade cost. Every release is a rebase against a large TypeScript tree, and the check-cyclic-dependencies script exists because the import graph is dense enough to break. Pinning to a tag is the only sane approach; tracking main means absorbing changes continuously.

The repository also publishes its process in the open. The README links a roadmap, monthly iteration plans, and endgame plans on the wiki, so you can see what is coming before it lands in a tag. If your fork depends on a specific built-in extension, that wiki is where to check whether it is scheduled to change.

Contributing without building the whole editor

The README lists contribution paths that do not require a full local build. You can submit bugs and feature requests, review source changes, or review the documentation repository and open pull requests for anything from typos to new content. There is a separate vscode-docs repository for that last one, which means a documentation fix does not touch this codebase at all.

For code, the README points at a How to Contribute wiki page covering building from source, the development workflow including debugging and tests, coding guidelines, submitting pull requests, and finding an issue. It also links a page on contributing translations. The test scripts in package.json are granular: test-node runs mocha against test/unit/node/index.js, test-browser runs the Playwright-based browser suite, and test-extension uses vscode-test. The root test script deliberately exits with an error message telling you to run a script from the scripts folder instead, which is a clear signal that there is no single test command.

One practical note: the README mentions AGENTS.md sits at the repository root alongside CONTRIBUTING.md, so automated contributors have their own instructions file separate from the human one.

Editorial conclusion

Adopt the Code - OSS repository if you need to read the editor's internals, patch a built-in extension, or build your own distribution under MIT. Do not adopt it if you want the Marketplace, the Microsoft-branded product, or a supported binary: the README points those users at code.visualstudio.com instead. Before committing, check that your machine or container has the 4 cores and 6 GB of RAM the README requests for a full build, and confirm which of the two licences applies to the artefact you plan to ship.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes