Ignore / don't auto-start Scala CLI for URIs outside workspace folders

[russwyte]

Describe the bug

When a VS Code / Cursor client sends textDocument/didOpen for Scala/sbt files outside the workspace folder(s) Metals was started with, Metals treats them as orphan/standalone sources and automatically starts Scala CLI BSP for each path. That floods the Problems panel with fake diagnostics (missing deps / wrong classpath) and burns CPU with many scala-cli bsp processes.

There is currently no user setting to disable this amplification (only the manual command scala-cli-stop, which does not stick across reloads).

Reproduction (observed in Cursor; any LSP client that opens out-of-workspace docs would hit this)

1. Open a single-folder workspace, e.g. /path/to/zipx only.
2. Metals starts correctly: Started … in folders '/path/to/zipx'.
3. The client then opens (or re-opens) documents outside that folder (in our case, sibling repos under the same parent directory; no visible editor tabs required).
4. Within ~1s Metals logs many lines like:
   • no build target found for /path/to/Anode/.../ProgressiveWebApp.scala
   • Running … scala bsp … --semantic-db-source-root /path/to/Anode/... ProgressiveWebApp.scala
   • Scala CLI started for /path/to/Anode/...
5. Problems fills with errors from those foreign projects; dozens of scala-cli BSP processes appear.

Wiping Metals H2 DBs (project/.metals, ~/Library/Application Support/metals, temp fallback-service*) and reloading the window does not help if the client keeps re-sending those didOpens.

Expected behavior

For document URIs outside the configured workspace folder(s):

1. Prefer not to auto-start Scala CLI BSP.
2. Ideally ignore / soft-handle them (no Problems pollution), or gate orphan Scala CLI behind an explicit setting defaulting to off for out-of-workspace URIs.
3. Optionally expose a setting such as metals.scalaCli.autoStart / metals.ignoreFilesOutsideWorkspace so users can opt out of the current behavior.

In-workspace true orphans / intentional Scala CLI scripts can keep today's behavior.

Why this matters

Editor agents (Cursor and similar) routinely touch files outside the opened folder and can leave sticky document state that survives reload. Metals then turns that into a severe UX failure (Problems noise + many Scala CLI BSPs) with no config escape hatch. Even if the client is wrong to send those didOpens, Metals should not make the failure catastrophic.

Metals / client versions

• Metals server: 1.6.8+2-01163379-SNAPSHOT (behavior is the general orphan → Scala CLI path in current Metals)
• Client: Cursor 1.128.0 / Cursor app 3.13.10 (VS Code–compatible LSP client)
• OS: macOS

Related client report

Filing a matching Cursor report about out-of-workspace document restore / didOpen to LSPs. Will link from a follow-up comment.

Proposal

• Skip automatic Scala CLI BSP startup when textDocument URI is outside workspace folders.
• Add a user configuration flag to control orphan Scala CLI auto-start (default: do not auto-start for out-of-workspace; optional: never auto-start).

[russwyte]

Client report status

cursor/cursor has GitHub issues disabled; posting the matching client report to forum.cursor.com and will link it here once live.

[russwyte]

Client report

Matching Cursor report (GitHub issues disabled on cursor/cursor; filed on their forum):

https://forum.cursor.com/t/lsp-didopen-for-files-outside-workspace-folder-poisons-language-servers-metals-scala/166710