vscode-R: the R extension, and the session layer it was rebuilt on

What the extension does, and what lives somewhere else

This VS Code extension provides support for the R programming language, including features such as R language service based on code analysis, interacting with R terminals, viewing data, plots, workspace variables and help pages, managing packages, and working with R Markdown documents.

The full documentation is in the project wiki, and the README points there for the details rather than duplicating them.

One structural detail comes first, because it catches people out. The R and R Markdown syntaxes are located in a sibling package, vscode-R-syntax. So a fresh install of this extension gives you the tooling without the colouring, and the syntaxes come from a second extension. The topics listed for the repository mention gitignore and rmarkdown alongside r and snippets, which is a sign of how many small concerns sit inside the extension package.

The feature list is broad enough to be worth summarising. There are snippets for R and R Markdown. The R Language Service gives code completion, function signature help, symbol highlighting, a document outline, formatting, go to definition, diagnostics and references. There is interaction with R terminals, sending code to a terminal, running multiple terminals and working with remote servers. There is package development support with the devtools commands, build, test, install, load all and others. There is a workspace viewer showing the global variables of the attached session, a help pages viewer for viewing and searching help topics, package management for installing and removing packages, and session symbol hover and completion.

The data viewer is the feature that goes furthest beyond a language server. It shows data frames, matrices, Arrow tables and polars data frames in a paged, sortable, filterable grid, and lists in a tree view. The plot viewer is an interactive viewer with support for the jgd and httpgd backends, plus a standard PNG and SVG fallback.

That list of column types, data frames, matrices, Arrow tables and polars data frames, tells you the viewer is built for people working with modern R data stacks rather than only with base data frames.

The 3.0 rewrite and the sess package

Version 3.0.0 is a major release, and the README describes it in one line: faster, more reliable R session communication, powered by the `sess` package.

The mechanism is worth understanding, because it explains the shape of the whole project. The extension includes `sess` and prompts to install or update the bundled copy when needed, and missing Imports are installed from the configured R repository.

So the session communication layer is no longer a set of ad hoc interactions with the R process. It is a package that ships with the extension, that the extension keeps current, and that has its own dependencies resolved through the user's configured R repository. The `sess` directory at the root of the repository is that package, and it has its own README.

The decision to bundle and self-update a package is a real trade. On one side, the extension controls the version of the transport it uses, so the fast and reliable behaviour is the default rather than something the user has to opt into. On the other, the extension is now writing into the user's R library, and a user who manages their R packages strictly may object to a package appearing and changing without them asking.

The `R/` directory at the repository root holds the other R-side code, and the separation of `R/` and `sess/` as two directories suggests the project treats the session layer as a distinct concern from the rest of the R integration.

Getting set up, and the version requirement that differs between the README and the manifest

The quickstart has four steps.

First, install R, version 3.4.0 or later, and on Windows the README recommends letting the installer write the R path to the registry. Second, install the `languageserver` package from R, with `install.packages("languageserver")`.

Third, install the extension, and the README says this release requires VS Code 1.110 or later. The installation is from the VS Code Marketplace or the Open VSX Registry, with `code --install-extension REditorSupport.r`.

There is a discrepancy here worth flagging, because it is the kind of thing that costs an hour. The README says the release requires VS Code 1.110 or later, while the package manifest's `engines` field declares `^1.98.2`. The manifest is what VS Code checks when it installs the extension, so on a build between those two versions the install will be permitted and the extension may then behave as if it is on a supported version. If you are on an older VS Code, the README's number is the one to believe.

Fourth, create an R file and start coding, and click Yes if prompted to install `sess`.

The steps 1 to 3 are all that is required, and the README says so explicitly before listing the recommended extras.

Pre-release channel, and the daily rebuild

The extension runs two channels, and the mechanism is described precisely enough to be worth reading.

For daily development updates, you choose Switch to Pre-Release Version on the extension's page in VS Code. New pre-releases are published to the VS Code Marketplace and the Open VSX Registry when `main` changes and verification passes. Switch to Release Version returns to stable releases, and when reporting problems you should include the extension version and reproduction steps.

There is also a way to install the development version directly from GitHub. The `latest` pre-release is updated after a successful verification of a push to `main`, and you download and install the vsix:

curl -fsSL -o vscode-R.vsix https://github.com/REditorSupport/vscode-R/releases/download/latest/vscode-R.vsix
code --install-extension vscode-R.vsix

So the release pipeline is: a push to `main`, a verification run, and a rebuild of the `latest` pre-release. The release list in the repository metadata shows exactly that, with a `latest` entry titled Development Build dated the same day as the last push, and v3.0.1 from 2026-09-28 and v3.0.0 from 2026-09-27 underneath it.

The package manifest version is 3.2.0 while the newest tag is v3.0.1, so the published pre-release is ahead of the tagged release line, which is what you would expect from a channel that rebuilds on every push.

For most users the stable channel is the right choice, and the pre-release channel is for people who want to file a good bug report against current main.

The recommended extras, and the plot backend decision

The recommended extras are optional, and the README groups them by what they improve.

For graphics there are two interactive plotting backends. jgd is a lightweight JSON graphics device with native integration in the extension, and httpgd is an SVG-based graphics device served over HTTP and WebSockets.

For the console, arf is a modern R console with syntax highlighting, multiline editing, vi and emacs keybindings, R version switching and more. It is described as the successor to radian and written in Rust.

And there are two complementary VS Code extensions, the official Quarto plugin and the VSCode-R-Debugger, which enables VS Code's debugging facilities for R scripts.

The settings example shows how these plug together, and the comment on the third line is the useful part:

{
    "r.consolePath": "arf",
    "r.bracketedPaste": true,  // recommended for arf (and radian)
    "r.plot.backend": "jgd"    // "auto" already prefers jgd, then httpgd
}

So the plot backend setting has an `auto` value that already prefers jgd and then httpgd, and you only need to set it explicitly to override that. The `r.bracketedPaste` flag is a requirement for arf and radian rather than a preference, because a console that does not understand bracketed paste will mangle multi-line input.

And there is a third behaviour worth knowing. Setting `r.plot.backend` to `native` uses R's configured graphics device without opening the VS Code plot viewer automatically, while the `standard` backend continues to display static plots in VS Code. That is for people who want plots in their own window rather than in the extension's pane.

The installation wiki pages are linked per operating system for Windows, macOS and Linux.

The repository layout, and the changelog tooling

The top level of the repository shows a project that keeps the R side, the extension side and the documentation tooling in separate places.

There is `R/` for the R code, `sess/` for the session package, `snippets/` for the R and R Markdown snippets, `syntaxes/` for the TextMate grammars and `language-configuration/` for the editor settings. The extension itself is in `src/`, and `scripts/` holds the build and release scripts, with `esbuild.js` as the bundler configuration. The `html/` directory holds the webview content, which is where the data viewer, the plot viewer and the help pages live, and `images/` holds the icons.

The tooling is current. The package manager is pnpm at 11.27.1 with a workspace file, and there is an `.oxlintrc.jsonc` for linting and a `.markdownlint.json` for the documentation. Testing has its own configuration, with a `.mocharc.interactive.cjs` and a `.vscode-test.mjs`, which is the standard arrangement for extension tests that need a real VS Code instance rather than a jsdom environment.

The changelog is generated rather than written. There is a `cliff.toml`, which is the configuration for git-cliff, a tool that builds a changelog from conventional commits, and the output lands in `CHANGELOG.md`. The `CHANGELOG.old.md` file next to it is the history from before that tooling was introduced.

There is also a `ThirdPartyNotices.txt` and a `LICENSE`, and the manifest's licence field says SEE LICENSE IN LICENSE rather than naming a standard identifier, which is what a project with a custom or multi-part licence does. The licence field in the repository metadata is recorded as MIT.

The `CONTRIBUTING.md` file and the wiki's installation pages complete the picture of a project that takes its contributor onboarding seriously enough to document it separately from the code.

Where vscode-R is the wrong choice

The first wrong case is a team that wants one extension to cover syntax and tooling. The syntaxes are in a separate package, and the README's first substantive line points at it. A user installing this extension and expecting colouring is going to have to install a second one, and an administrator rolling the extension out to a fleet has to roll out both.

The second wrong case is a user on an older VS Code. The README's stated requirement is 1.110 or later, and the manifest's engine range is older than that, so the install may succeed and the behaviour may not. The extension is closely tied to the VS Code API and to the way the webview panels are registered, so an old build is not a good bet.

The third is a user who does not want R packages written into their library without asking. The bundled `sess` package is installed and updated by the extension, and the `languageserver` package has to be installed separately too. A managed R environment, where the package set is locked down, needs that flow planned for.

The fourth is a developer who wants the pre-release channel and a stable one at once. The two channels are mutually exclusive in the VS Code interface, so a machine that tracks main for bug reports and stable for daily work is two installs.

The fifth is someone who only needs a text editor with R colouring. The language service, the data viewer and the plot viewer are the reason to install it, and if you only want the colours, the separate syntax extension is the smaller answer.

Editorial conclusion

vscode-R suits an R developer who wants completion, diagnostics, an interactive data grid and a plot pane inside the editor rather than in a separate IDE, and who is willing to install the `languageserver` R package and keep the extension up to date. It does not suit a team that wants a single extension covering syntax and tooling, because the syntaxes live in the separate vscode-R-syntax package, and it does not suit anyone pinned to an old VS Code build. Before installing, check the version requirement, since the README says VS Code 1.110 or later while the package manifest still declares an older engine range, and decide whether you want the stable channel or the daily pre-release, which is rebuilt every time `main` changes.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. REditorSupport/vscode-R on GitHub
5. Releases