Summary
When open_workspace is called in checkout mode with a nonexistent path under an allowed root, DevSpace silently creates that directory and opens it as an empty workspace.
This is surprising for an operation named open_workspace, and it can turn an MCP client's guessed path into a real directory. The client may then inspect the newly created empty directory and incorrectly conclude that the intended project is empty.
Reproduction
Assume the allowed root is:
The real project exists at:
/Users/example/work/sample-project
-
Call open_workspace with a plausible but incorrect path:
/Users/example/sample-project
-
The call succeeds and returns a workspaceId.
-
DevSpace creates /Users/example/sample-project as a new empty directory.
-
A subsequent directory listing reports an empty workspace.
I observed the filesystem creation time and the persisted workspace_sessions.created_at timestamp matching to the same second for the newly created directory and workspace session.
Expected behavior
Checkout mode should reject a nonexistent workspace path with a clear error, for example:
Workspace path does not exist
If directory creation is desired, it should require an explicit opt-in such as createIfMissing: true, with the default remaining non-mutating.
Actual behavior
ensureCheckoutWorkspaceRoot() catches ENOENT and runs:
await ops.mkdir(path, { recursive: true });As a result, a path inference error becomes a filesystem mutation and a valid-looking empty workspace.
Why this matters
LLM clients can infer or guess project paths when users provide only a folder name. Silently creating the guessed path:
- hides the original path error;
- can produce confidently incorrect answers about project contents;
- leaves unexpected directories on the user's machine;
- makes a read/inspection request perform an unrequested filesystem mutation.
Environment
- DevSpace 1.0.5
- macOS
- Checkout mode
- Reproduces independently of whether the minimal or codex tool surface is selected
Summary
When
open_workspaceis called in checkout mode with a nonexistent path under an allowed root, DevSpace silently creates that directory and opens it as an empty workspace.This is surprising for an operation named
open_workspace, and it can turn an MCP client's guessed path into a real directory. The client may then inspect the newly created empty directory and incorrectly conclude that the intended project is empty.Reproduction
Assume the allowed root is:
The real project exists at:
Call
open_workspacewith a plausible but incorrect path:The call succeeds and returns a
workspaceId.DevSpace creates
/Users/example/sample-projectas a new empty directory.A subsequent directory listing reports an empty workspace.
I observed the filesystem creation time and the persisted
workspace_sessions.created_attimestamp matching to the same second for the newly created directory and workspace session.Expected behavior
Checkout mode should reject a nonexistent workspace path with a clear error, for example:
If directory creation is desired, it should require an explicit opt-in such as
createIfMissing: true, with the default remaining non-mutating.Actual behavior
ensureCheckoutWorkspaceRoot()catchesENOENTand runs:As a result, a path inference error becomes a filesystem mutation and a valid-looking empty workspace.
Why this matters
LLM clients can infer or guess project paths when users provide only a folder name. Silently creating the guessed path:
Environment