Can I config allowed paths?

[gusye1234]

Great Project!
I'm wondering how can I pass the allowed paths for desktop-commander? Maybe like mcp/filesystem?

[wonderwhy-er]

Yeah, I had it but for simplicity removed it.
I am experimenting with MCP having a config that can be modified by MCP
So you can just ask LLM to add or remove folders its allowed to work with.

Only issue is that it will be circumventable trough terminal access.
Aka it will go and try to access file system, fail. And then will decide to go and access trough terminal.

And for terminal its way harder "lock" and can result in unintended consequences where things like module installation does not work as it effects things outside of your folder.

So for now for simplicity sake I decided not to put such limitations.
Usually if you tell it to work in concrete folder it respects that.

What is your use case and how are you blocked about it?

[joshmouch]

I'd like this as well. In Windows, I tried creating a junction, a symbolic link, and a disk partition path all rooted under my user folder so that the MCP server would have access to the folder I'm trying to get to, but all result in an error similar to:

{
  `path`: `C:\\Users\\josh\\mnt\\Dev\\Source\\VsCode\\Kerbal-Cline`
}
Error: Parent directory does not exist: C:\Users\josh\mnt\Dev\Source\VsCode

Your plugin treats the "C:\users\Josh\mnt\Dev" part (which is the link) as a file instead of as a folder.

While I'm OK with the symbolic link approach, that's some advanced user stuff. So just allowing for folder configuration is the better option.

[giannischatzo]

One extra use case would be WSL directories. As it is now you don't have access to them as they're neither under the working directory or the user directory. One workaround would be to be able to change the working directory

[jasondsmith72]

I used claude to edit this to give it full access to to everything, you have to run as admin. it started off as a fork then somehow it broke free of that fork, here is the code, please take a look and see if you can intergrade it into your https://github.com/jasondsmith72/UDC, I did try to allow it to be configurable but that didn't seem to work, so I left it open,

I was able to have claude go through and diag my computer found issues from event viewer with drivers and it fixed it. one issue I"m having though is it seems to have a hard time using ssh. I really want it to be able to ssh to a Linux server and do stuff there :)

Another risky thing I want to add is powershell to 365 and make changes there and or to a server and run powershell to make changes there. :)

P.S. I don't know how to code at all lol

[wonderwhy-er]

I started working on such configurations, need to test them first.
I want it to be possible to edit those from chat in that sense.
There were already asks to allow changing default shell, cmd, zsh, wsl and so on.
Root directory or list of those would be another thing to put in to such config.

[jasondsmith72]

Awesome can't wait for the update :)

[briankgarland]

Yeah, that would be great. I can't get it to work with anything other than c:\users\myusername.

[wonderwhy-er]

Pushed PR but its not finished
Work in progress
#16

[wonderwhy-er]

I just pushed in new version
Should update itself on restart of claude(though if you instealled trough smithery it may crash on first restart, you need to restart once more)

In new version I commented out folder validation so all disk drives and paths are allowed now

I will allow restriction again when its configurable
For now it unlocks use in different cases

[MatrixManAtYrService]

Just an idea about how to handle this: it would be cool to have some kind of "probe" that you could run that would temporarily:

• grand desktop commander access to the probe's CWD
• ensure that commands that were run in that dir have the same uid, gid, env vars, and cwd as the probe (these would be inherited automatically from the calling shell as long as the commands run as subprocesses of the probe process).

This way if I have a temporary environment (like a nix devshell or a python venv), I can run the probe in that environment and Desktop Commander commands would have access to whatever versions of things were part of that environment. Similarly, one could craft restricted environments to disallow certain kinds of access (e.g. to secrets).

As it is, I'm just running claude desktop from a shell in that environment but its cumbersome because I still have to alter the global config file--I can't have per-project config files.

This would prevent the need to change the config file whenever you wanted it to work on a different project, you'd just Ctrl-C the probe from over here, and run it over there and the scope of access would be changed too. One could even imagine putting the probe in a VM or on the other side of an SSH connection.

---

Even in the absence of such a feature, I think you could just run claude desktop (or whatever else calls Desktop Commander) as a user with limited access... Better to lean on the battle-hardened permissions systems already provided by your OS than to duplicate such a thing in each MCP-server you use.

[wonderwhy-er]

Just an idea about how to handle this: it would be cool to have some kind of "probe" that you could run that would temporarily:

• grand desktop commander access to the probe's CWD
• ensure that commands that were run in that dir have the same uid, gid, env vars, and cwd as the probe (these would be inherited automatically from the calling shell as long as the commands run as subprocesses of the probe process).

This way if I have a temporary environment (like a nix devshell or a python venv), I can run the probe in that environment and Desktop Commander commands would have access to whatever versions of things were part of that environment. Similarly, one could craft restricted environments to disallow certain kinds of access (e.g. to secrets).

As it is, I'm just running claude desktop from a shell in that environment but its cumbersome because I still have to alter the global config file--I can't have per-project config files.

This would prevent the need to change the config file whenever you wanted it to work on a different project, you'd just Ctrl-C the probe from over here, and run it over there and the scope of access would be changed too. One could even imagine putting the probe in a VM or on the other side of an SSH connection.

Even in the absence of such a feature, I think you could just run claude desktop (or whatever else calls Desktop Commander) as a user with limited access... Better to lean on the battle-hardened permissions systems already provided by your OS than to duplicate such a thing in each MCP-server you use.

Interesting.
I think real solution is bit different.
You speak of SSH and virtual envs and such.
How do you yourself work with them? You start terminal and type in command to start the env or connect to ssh right?

Way DC works currently is that for each command it starts new terminal
That is okey for usual commands but not for those that should keep enviroment and be interactive

It seems to me that real solution is to allow running interactive shells to which DC can write and from which it can read.
And then you could start ssh or virtual environment sessions in those.
How does that sound?

Only issue is to close them before leaving the chat :D

[MatrixManAtYrService]

I'm very new to working with MCP servers at all, so if there are established ways of doing things in this space, I might be ignorant of them. I'm sort of shooting from the hip here.

It seems to me that real solution is to allow running interactive shells to which DC can write and from which it can read.

I think I like this idea, but I'm not sure whether you mean that I would run a process that would contain this shell and somehow give DC control over it, or if I'd be asking the model to start a shell through DC. I would prefer the former because then I don't have to worry that the model will later decide to do something differently. This is somewhat relevant for things like virtual environments, but especially important if I'm telling the OS to restrict access in some way.

For instance, suppose I have secrets stored in files which the user claude does not have read access to. If I run something like:

sudo -u claude dc-probe --shell /bin/bash

Then I know that the model will not be able to do anything with those secrets because the operating system will not allow that process to read the secret files.

On the other hand, if it's DC that starts the shell, then I have to worry that maybe the model will be like:

I see that the claude user doesn't have access to this file, I'll just give myself a different shell as the root user...

The OS already has a battle hardened way of restricting/enabling the behavior of processes, so it seems simpler to give the user a way to place DC under user/os-customized control.. Having DC handle the specification of whatever environment the shell runs in would make me less certain that it's going to so do reliably.

[mbilokonsky]

Related to this, so commenting here instead of opening a new issue, but: are there any protections in place to prevent DC from reading .env or ~/.zshrc or similar? I'm wondering if just adding a config variable that prevents access to dotfiles (or anything with a dot-prefixed directory in its path) would solve this?

I'd like to use this, but I don't want to take the risk that keys get sent to anthropic's logs anywhere.

Bonus points if this recognizes dotfiles in the shell script command, too, and maybe requests explicit permission before it runs eg cat ~/.ssh/* or whatever?

Extra bonus points if it can, like, run a filter against shell output to replace anything that matches the pattern of an .ssh key or an access token?

To me this is a hard block that would prevent me from using this on most projects, especially client work.

[wonderwhy-er]

We finally released new version that allows to set allowed paths
Here are more notes for that release
https://github.com/wonderwhy-er/DesktopCommanderMCP/releases/tag/v0.1.35

In theory there are some improvements as currently we only have white list allow url collection.

Which may be cumbersome to use in some cases or disallow more complex situation of allowing one path but blocking some of the sub paths.

For now we will close this issue but further feedback is welcome.