FAQ

Does vrOS need SteamVR running?

No. vrOS is a desktop application first, and VR is a presentation layer that attaches when a runtime is there. Without a headset you get the desktop window: the overlay list, settings, and any extension that does its work on the host OS. The process that talks to the VR runtime is only spawned when it is needed.

When SteamVR is already running, vrOS attaches to it.

Does starting vrOS start SteamVR?

No, not unless you opt in. vrOS detects a running runtime by looking for its process; it never launches one, and it never probes by initializing a runtime API. The one path that can start SteamVR is an explicit user action behind a setting that is off by default.

Does closing SteamVR close vrOS?

No. When the runtime quits, vrOS tears down its VR side and keeps running: the core app, your settings, your capture list, and your extensions are all untouched. There is a setting to quit with SteamVR if that is what you want, and it is off by default.

The reverse holds too. A SteamVR crash does not take vrOS with it, and your overlays come back on their own when the runtime does. See Troubleshooting.

Does it run on Linux?

Yes, on x86-64, both desktop Linux and SteamOS. Both Linux VR stacks work: SteamVR for Linux through OpenVR, and Monado and WiVRn through OpenXR. vrOS ships a backend for each, because neither stack implements the other’s overlay API. Capture goes through your desktop’s screen-sharing portal.

Does it run on Steam Frame?

Native, on-device Steam Frame support is in development, not shipped. Two hardware questions are still open: which overlay path the on-device runtime accepts, and what can be captured there. It gets called supported once it is verified on the device, and not before.

Frame’s main mode does work today. When you stream wirelessly to a Frame from a Windows or Linux PC, vrOS runs on the PC inside SteamVR like it does for any other PCVR headset, with no Frame-specific work.

Does it work with headsets that are not SteamVR?

If the headset’s runtime is one vrOS speaks, yes. There are two overlay backends: OpenVR for SteamVR on Windows and Linux, and the OpenXR overlay extension for Monado and WiVRn. Everything above that line is runtime-agnostic.

How do I get it?

On Steam, app 3873610. One purchase covers every platform it supports. Install walks through the first launch.

What languages is it in?

Nine, everywhere in the app, with no English-only strings: English, Deutsch, Español (Latinoamérica), Français, Italiano, 日本語, 한국어, Русский, and 简体中文. The language picker lists endonyms, not flags — a flag is a country, not a language. The VR keyboard ships six built-in boards: English at 70, 80 and 100 percent, Korean 두벌식, Japanese romaji, and the Japanese 12-key flick board.

These documentation pages are English only for now.

Can I use it without controllers?

Yes. Every surface is operable three ways, and all three are supported on every screen rather than a subset: laser and controller, gamepad-only focus traversal, and plain mouse and keyboard on the desktop. Nothing is hover-only.

Gaze plus a confirm is designed in throughout — the degree floors, the focus hysteresis, the dwell rules — but gaze pointing is not in the build yet, and there is no setting for it. See Input and authority.

Does vrOS collect any data?

No. There is no network surface, no telemetry, and no remote control. Everything vrOS does is local to the one machine it runs on and visible to the person wearing the headset, and nothing it observes leaves the machine.

Two specifics worth naming, because the mechanisms sound alarming out of context. Window observation is scoped to the captures you chose: it starts when you bind a capture and ends when you unbind it, and there is never a global hook. Text awareness is position-only — vrOS learns that an insertion point exists in a captured window and where it is, so the keyboard can behave; it does not read your text or read keystrokes back.

Extensions are separate. An extension that talks to the network declares it, and you see that on the consent screen before it first runs.

Does vrOS need administrator?

No, and it deliberately does not elevate itself. One consequence is worth knowing: Windows refuses injected input into a window running as administrator, so clicks and keys from a panel will not reach one. The source picker badges those windows.

Which v1 features are in 2.0.0?

Not all of them, and it is better to say so plainly. 2.0.0 ships the foundation done well: overlays, the VR keyboard, input authority, the performance panel, playspace tools, and the audio engine. Creator features come back incrementally as extensions rather than all at once.

In the launch set: VRChat OSC, OBS control, and the soundboard. Twitch chat is being built as an extension on the same API and has no release date yet. Release notes record what actually shipped in each version.

Can I write my own extension?

Yes. Extensions speak one protocol over a local socket, contribute UI as Slint panels that vrOS renders itself, and ask for the specific capabilities they use — which you grant the first time you enable one, and can revoke later in Settings → Extensions. Third-party extensions use the same API the built-in ones do; that is deliberate, because it is how the API stays honest.

The first release installs extensions from a local folder with a consent screen listing what they asked for. Start at Build an extension.

Where are my settings and layouts kept?

Settings live in %APPDATA%\vrOS\config.toml on Windows and $XDG_CONFIG_HOME/vros/config.toml on Linux. The file appears the first time you change a setting.

Overlays, saved presets, and custom keyboard layouts are not config: they live in vrOS’s own database and are restored when it starts. Extensions get their own persistent store, which is why an extension’s state survives a runtime crash, an app restart, and a reboot.