'allowedRoots' have some problems

[MinanaYaa]

No matter how I set the parameter, Chagpt Web can only access C:\Users\Administrator and can even perform operations under that document, which is extremely dangerous.

[Waishnav]

did you instructed it to open workspace in C:\Users\Administrator?

[MinanaYaa]

did you instructed it to open workspace in C:\Users\Administrator?

I didn't give any instructions; just simply created a new chat and asked GPT for the local project folder set in devspace.

[Waishnav]

don't know maybe try forking devspace and try explaining it to codex or chatgpt through devspace and see if it's solvable. I can't reproduce this since i'm not on windows

[MinanaYaa]

Cheers! Such a dope project, I’ll try fixing this problem. ～only ***@***.***

[Ahmed-Hindy]

I have the same bug, codex auto found it and fixed it. I haven't tested it since I need to restart the server. here is codex's reply:

Here’s a paste-ready Markdown comment:

I was able to reproduce a likely root cause for this on Windows.

## Summary

`allowedRoots` can be bypassed on Windows when the requested path and the configured allowed root are on different drives.

Example:

```ts
allowedRoots = ["G:\\Projects\\Dev\\Github\\devspace-1.0.2"];
requestedPath = "C:\\Users\\Ahmed Hindy";

The expected behavior is that C:\Users\Ahmed Hindy is rejected because it is outside the allowed G:\... root.

The observed behavior is that the path can be accepted, allowing ChatGPT/MCP tools to open and write outside the configured allowlist.

Why it happens

The containment check appears to rely on path.relative(root, path) and then rejects paths that start with ...

That works for same-drive paths, for example:

path.relative("G:\\Projects\\Dev", "G:\\Projects\\Other");
// "..\\Other"

But on Windows, when the two paths are on different drives, path.relative() returns an absolute path:

path.relative(
  "G:\\Projects\\Dev\\Github\\devspace-1.0.2",
  "C:\\Users\\Ahmed Hindy"
);

// "C:\\Users\\Ahmed Hindy"

That result does not start with .., so a check like this can incorrectly treat it as inside the allowed root:

relationship === "" ||
(!relationship.startsWith("..") &&
 relationship !== ".." &&
 !relationship.includes(`..${sep}`))

The missing condition is: the relative result must also not be absolute.

Security impact

This is a high-impact allowlist bypass.

If DevSpace is configured with a narrow root such as:

G:\Projects\Dev\Github\my-project

an MCP client may still be able to open and modify:

C:\Users\<user>

or potentially other paths on a different Windows drive.

That defeats the main filesystem safety boundary of allowedRoots.

Suggested fix

Update the path containment check to reject absolute path.relative() results:

import { isAbsolute, relative, resolve, sep } from "node:path";

export function isPathInsideRoot(path: string, root: string): boolean {
  const resolvedPath = resolve(expandHomePath(path));
  const resolvedRoot = resolve(expandHomePath(root));
  const relationship = relative(resolvedRoot, resolvedPath);

  return (
    relationship === "" ||
    (!isAbsolute(relationship) &&
      !relationship.startsWith("..") &&
      relationship !== ".." &&
      !relationship.includes(`..${sep}`))
  );
}

The important added check is:

!isAbsolute(relationship)

This catches the Windows cross-drive case.

Regression test

A Windows-specific regression test should cover different-drive paths:

if (process.platform === "win32") {
  assert.throws(
    () =>
      assertAllowedPath(
        "C:\\Users\\Ahmed Hindy",
        ["G:\\Projects\\Dev\\Github\\devspace-1.0.2"],
      ),
    /Path is outside allowed roots/,
  );
}

Notes

This is probably why users are seeing ChatGPT access C:\Users\... even when allowedRoots is configured to a different project directory.

I verified locally that adding !isAbsolute(relationship) makes the cross-drive path correctly fail the allowlist check.

=== END CODEX REPLY ===

@MinanaYaa @Waishnav 

[Waishnav]

@Ahmed-Hindy since i can't test it myself, so instead of sharing codex's response, do raise the PR with attached manual QA/test video by reproducing it

[Ahmed-Hindy]

@Waishnav Done #40

[Waishnav]

@Ahmed-Hindy do attached the manual QA/testing video from your windows machine

[Ahmed-Hindy]

@Waishnav Not sure why would I need to post a video. I am not comfortable doing that for privacy reasons. I however, updated the PR with my manual findings and tests. It should be way clearer now. If you want me to conduct more manual testing, I am all in.

[Waishnav]

@Ahmed-Hindy it will just help me validate everything is working as intended since i can't run it from windows and test it myself, nvm it seems good enough for now, since changes are bit smaller