[BUG] Problems without an open workspace

[utilisateuralpha]

Hello,
I'm currently experiencing some issues using the IDE without an open workspace:

1. When I type a 'Hello' message in the chat, the assistant unnecessarily tries to access the $HOME/Desktop folder. Furthermore, this path is incorrect on my system because my home folder is named "desktop" (with a lowercase "d").

2. Without a workspace, the @file functionality doesn't recognize files that are open in the editor.

[taltas]

@utilisateuralpha , thanks for bringing this up. I'm curious, is there a paritcular reason you are using zoo without a workspace?

[utilisateuralpha]

@taltas
This is completely normal behavior. I use it to open standalone files that don't belong to any specific project. In fact, I don't limit my use of VS Code to development alone; I use it as a versatile editor to read and modify any text file.

[taltas]

@zoomote can you look into why this might be happening? Do an investigateion and report back here. Dont cut a PR.

[zoomote]

I traced both symptoms through the current code. They are reproducible from the control flow and appear to be longstanding no-workspace design gaps rather than a recent regression.

Root cause 1: $HOME/Desktop is a synthetic workspace

When a task starts without an explicit workspace, Task falls back to getWorkspacePath(path.join(os.homedir(), "Desktop")) (Task.ts:514-518). In an empty VS Code window, an open standalone file has no containing workspace, so getWorkspacePath() returns that supplied fallback (path.ts:152-167).

That means the task's effective cwd becomes exactly $HOME/Desktop, even when that directory does not exist or the actual desktop is lowercase, localized, XDG-configured, redirected, or elsewhere.

A plain greeting can touch that synthetic path before the model requests a tool: task construction creates and initializes RooIgnoreController (Task.ts:522-528), which creates a watcher and checks <cwd>/.rooignore (RooIgnoreController.ts:21-26, RooIgnoreController.ts:64-76). The prompt also identifies that path as the current workspace, so subsequent model tool use is rooted there.

There is already a special case that suppresses the initial recursive listing for the exact capitalized $HOME/Desktop path because it can trigger a permission prompt (getEnvironmentDetails.ts:229-246). That mitigation does not cover ignore/rules probes or later tools, and it cannot recognize lowercase/localized/redirected desktops.

Root cause 2: open tabs are discarded without a workspace

The provider-level cwd is empty in an empty window (ClineProvider.ts:3632-3634). WorkspaceTracker can enumerate TabInputText tabs, but workspaceDidUpdate() exits when cwd is empty, before sending openedTabs to the webview (WorkspaceTracker.ts:76-91, WorkspaceTracker.ts:112-126). Initialization also returns before publishing anything when there is no cwd (WorkspaceTracker.ts:27-39).

The @file menu relies on those openedTabs entries (ChatTextArea.tsx:275-294). Its secondary typed search also explicitly returns no results when no workspace path exists (webviewMessageHandler.ts:2020-2031). Therefore both discovery paths are disabled.

flowchart LR
    A[VS Code window without workspace] --> B[Task startup]
    B --> C[Fallback cwd = HOME/Desktop]
    C --> D[Ignore/rules probes and model tools use Desktop]
    A --> E[Provider cwd is empty]
    E --> F[WorkspaceTracker suppresses openedTabs]
    E --> G[searchFiles returns no results]
    F --> H[@file cannot see standalone files]
    G --> H

Loading

Important implementation constraint

Removing the WorkspaceTracker guard alone would not be sufficient. It currently computes tab paths relative to this.cwd || "", while selected mentions are later resolved relative to the task cwd (mentions/index.ts:265-277). With no workspace, that can produce arbitrary ../../... paths and then resolve them against the unrelated synthetic Desktop root. Standalone files need an explicit URI/absolute-path representation through the host-to-webview-to-mention pipeline.

Recommended fix plan

1. Introduce explicit workspace-less task semantics instead of treating $HOME/Desktop as a real workspace. If a file-backed active editor exists, use a deliberate base such as its parent for relative operations; if none exists, use a safe extension-owned empty working directory or disable workspace-relative filesystem operations until the user selects a root.
2. Publish open file-backed editor tabs even when workspaceFolders is empty. Carry a stable URI/absolute identity for standalone files rather than deriving a path relative to an empty string.
3. Extend @file mention resolution so a standalone opened-file entry resolves to that exact URI, while retaining workspace-relative behavior for normal workspaces and preserving ignore/approval boundaries.
4. Keep broad filesystem search disabled without an explicit root; only expose files the user has already opened unless a folder/workspace is selected.
5. Add unit coverage for no workspace + standalone tab, no workspace + no active file, lowercase/localized/nonexistent Desktop cases, and exact mention resolution across multiple directories (including spaces and Windows paths). Add one VS Code e2e regression because tabGroups, standalone-file URIs, and empty-window behavior depend on the real extension host.

I ran the focused existing suites for path selection, workspace tracking, and file search: 3 files / 48 tests passed. Those tests confirm the current fallback and no-workspace search behavior, but there is no standalone-file/no-workspace coverage today. History shows the Desktop fallback and opened-tab workspace guard were introduced separately, which matches this being a longstanding interaction rather than one recent change.

No code was changed and no PR was opened. Tag @zoomote if you want me to turn this into an implementation plan or fix in a separate task.