astral-sh/ruff · error

Workspace URI is not a file path: {uri}

Error message

Workspace URI is not a file path: {uri}

What it means

While handling workspace/didChangeWorkspaceFolders (removal), uri.to_file_path() failed for the submitted workspace URI, so ty cannot map the folder to a filesystem path (session.rs:800). Only file-scheme URIs can be converted; untitled:, vscode-virtual:, or other schemes cannot.

Source

Thrown at crates/ty_server/src/session.rs:800

    /// Removes a workspace folder at the given URI.
    ///
    /// This removes the workspace folder and its associated project database,
    /// and clears diagnostics for any documents that were in the workspace.
    ///
    /// # Errors
    ///
    /// This returns an error if the workspace folder has already been removed
    /// or otherwise could not be found.
    pub(crate) fn remove_workspace_folder(
        &mut self,
        client: &Client,
        uri: &Uri,
    ) -> anyhow::Result<()> {
        tracing::info!("Removing workspace folder: {uri}");

        let path = uri
            .to_file_path()
            .map_err(|()| anyhow!("Workspace URI is not a file path: {uri}"))?;
        let workspace_path = SystemPathBuf::from_path_buf(path)
            .map_err(|path| anyhow!("Workspace path is not valid UTF-8: {}", path.display()))?;

        anyhow::ensure!(
            self.workspaces.unregister(&workspace_path),
            "Workspace not found: {uri}",
        );

        // Note that it is somewhat unclear whether we actually need to
        // clear diagnostics here. It seems that, at least in the case
        // of VS Code, it will auto-clear any diagnostics not found in
        // the workspace diagnostic response. Moreover, VS Code will
        // re-request workspace diagnostics after removing a workspace
        // folder.
        //
        // For now, we keep unconditionally clearing diagnostics on
        // opened text documents for reasons of good sense, but it's
        // possible that we don't even need to do that (when workspace

View on GitHub (pinned to 672bb4edf0)

Solutions

1. Only send removals for `file://` workspace URIs you previously added
2. Filter workspaceFolders on scheme === 'file' before forwarding to the server
3. Ignore this error for virtual folders — the server never had them registered

Example fix

// before
client.notify('workspace/didChangeWorkspaceFolders', {
  event: { removed: [{ uri: 'untitled:Workspace-1', name: 'ws' }] },
});

// after
client.notify('workspace/didChangeWorkspaceFolders', {
  event: { removed: folders.filter(f => f.uri.startsWith('file:')) },
});

// TS: filter to file URIs before forwarding folder changes
const removable = removed.filter(f => f.uri.startsWith('file:'));
if (removable.length) {
  client.notify('workspace/didChangeWorkspaceFolders', { event: { removed: removable } });
}

const isFileUri = (uri: string): boolean => {
  try { return vscode.Uri.parse(uri).scheme === 'file'; }
  catch { return false; }
};

When it happens

Trigger: Sending a workspace folder removal whose URI is not a `file:` URI — e.g. `untitled:`, a virtual-document scheme, or a remote scheme that lsp-types cannot convert to a path.

Common situations: Remote/browser editors forwarding non-file workspaces, extensions adding virtual folders, or clients echoing back URIs the server never registered.

Related errors

• Workspace path is not valid UTF-8: {}
• Workspace not found: {uri}
• Workspace URI is not a file or directory: {uri:?}
• Workspace URI is not valid UTF8
• Failed to get the current working directory while creating a

AI-assisted analysis of astral-sh/ruff@672bb4edf0 (2026-08-16). Data as JSON: /api/errors/d75fb98e3235e26e. Report an issue: GitHub.