Save as admin option.

[IntelligentFunction]

Please allow saving of files as admin, currently it is not possible to edit or create service files unless logged in as root and there is no way to open a file with sudo.

[roblourens]

The root issue is here: microsoft/vscode#48659

[Chuxel]

I suspect this is also applicable to containers and WSL.

[sergei3000]

Waiting on this feature badly. Please move this up your priority queue.

[cybermike844]

I'd like to request this for SSH as well

[CalSmith1]

I was referred to this issue since I cannot navigate as sudo after using ssh plugin to connect. Please expedite this issue. Thanks

[BenjaminHolland]

Can we get an update on this? It seems to have been silently dropped from #2973.

[jnooree]

Any updates, please? This is one of the most wanted features for system admins.

[LSafer]

Any updates? I really don't want to use vim or scp

[geochanto]

Another vote up for this. This is super important. Unless using root user, not having this renders remote-ssh almost useless.

[piwawa]

I want to edit a file and save, but always alarm me NoPermission just like this:

The reason why i use VSCODE to connect remote machine is to use the code editor, but i can't even save a limited file and no option to save as root, and still need to sudo nano ..., that is so annoying and troublesome !!

[Logophoman]

Same issue here 😕 - please update this 👍

[nnfans]

Here's the workaround microsoft/vscode#48659 (comment)

[khalidx]

Oh do I have the solution for you!

Here's how I solved it. Clean, and just works, with no weird modifications or settings.

Add an alias to your ~/.bashrc or ~/.bash_aliases:

alias sudocode='SUDO_EDITOR="$(which code) --wait" sudoedit'

It's just a wrapper around the built-in sudoedit command which allows editing of files with sudo and VSCode.

So just type sudocode /etc/some/privileged/file.conf to edit any privileged file in your system in VSCode!

By the way, this works locally and also works when you are using SSH, a Dev Container, or WSL.

[mldisibio]

@khalidx Brilliant! Reading how sudoedit works, this is what I recommended to solve this problem anyways. Copy the privleged file to a local workspace with user permissions. Edit. Copy back as sudo. Even Windows Servers require this pattern. But sudoedit simplifies all those steps into one command, copying the file to /var/temp. Thus you are not locking the file while editing and you can safely undo mistakes before saving.

[piwawa]

Oh do I have the solution for you!

Here's how I solved it. Clean, and just works, with no weird modifications or settings.

Add an alias to your ~/.bashrc or ~/.bash_aliases:

alias sudocode='SUDO_EDITOR="$(which code) --wait" sudoedit'

It's just a wrapper around the built-in sudoedit command which allows editing of files with sudo and VSCode.

So just type sudocode /etc/some/privileged/file.conf to edit any privileged file in your system in VSCode!

By the way, this works locally and also works when you are using SSH, a Dev Container, or WSL.

Useless, can't even click and open a root privleged file when using normal user to SSH connect.

[khalidx]

@piwawa you are probably doing something wrong. What isn't working / is useless?

When you are using SSH to connect as a normal user, yes, you can click and open any file. The problem is when you save you won't be able to since VSCode does not support elevating permissions when it comes time to save. This feature is being worked on.

Most people are not mounting / in VSCode, usually you are in some subdirectory but then need to jump and edit some config file. What you can do as an alternative is instead of clicking the file in the file browser (since /etc likely won't be in your file browser anyway) you can type sudocode /etc/some-file and it will pop the file open in your current VSCode window with the appropriate permissions to let you save the file too (as mentioned here: #1688 (comment)).

[PeterWone]

Useless, can't even click and open a root privleged file when using normal user to SSH connect.

That was rude. Try to remember that it's not always about you and your specific conditions and needs. I say this as someone who occasionally forgets this.

[PeterWone]

You say you are altering the behaviour of sudoedit which clearly isn't a thing on my Windows workstation. Does this mean you have assumed the workstation runs Linux?

I think this implies I can't use this approach with my workstation running Windows, is that right? Or perhaps wsl could help?

[mldisibio]

You say you are altering the behaviour of sudoedit which clearly isn't a thing on my Windows workstation. Does this mean you have assumed the workstation runs Linux?

@khalidx solution is adding a command to your user profile on the remote server where you are trying to edit files that require elevated permissions as root to edit. So it has nothing to do with the client that is remoting to the linux server. When you ssh into a remote linux host with VS Code, it as if you are logged into the linux terminal. You can be running VS Code from Windows, from Windows WSL, or from another linux box, but you are communicating with and are working in the context of a virtual VS Code service running on the remote host. Hope that clarifies.

The assumption is that if you can remote into the server, you have a bash profile you can edit. I suppose possibly in a cloud environment that might not be the case.

[PeterWone]

You say you are altering the behaviour of sudoedit which clearly isn't a thing on my Windows workstation. Does this mean you have assumed the workstation runs Linux?

@khalidx solution is adding a command to your user profile on the remote server where you are trying to edit files that require elevated permissions as root to edit. So it has nothing to do with the client that is remoting to the linux server. When you ssh into a remote linux host with VS Code, it as if you are logged into the linux terminal. You can be running VS Code from Windows, from Windows WSL, or from another linux box, but you are communicating with and are working in the context of a virtual VS Code service running on the remote host. Hope that clarifies.

The assumption is that if you can remote into the server, you have a bash profile you can edit. I suppose possibly in a cloud environment that might not be the case.

I do have a bash profile I can edit. The reason I thought it implied a Linux workstation is that he's changing sudoedit, and in order to use sudoedit I'd have to do it from my bash prompt. As I understand remote workspaces, vscode runs natively on my workstation and a proxy runs on the remote host. The sudoedit command would be running on the remote host. I think there must be something about this solution that I don't understand.

[mldisibio]

I do have a bash profile I can edit. The reason I thought it implied a Linux workstation is that he's changing sudoedit, and in order to use sudoedit I'd have to do it from my bash prompt. As I understand remote workspaces, vscode runs natively on my workstation and a proxy runs on the remote host. The sudoedit command would be running on the remote host. I think there must be something about this solution that I don't understand.

Perhaps it's not clear. When you remote into the server, you would open the terminal (e.g. CTL+`) and that is the actual bash prompt from your server that has loaded your '.bashrc' profile with @khalidx nifty 'sudocode' command shortcut that under the covers invokes sudoedit in your terminal session and tells it to use vscode (running on the linux host) as your editor. 'sudoedit' is running on the server, not from your workstation.

[PeterWone]

Perhaps it's not clear. When you remote into the server, you would open the terminal (e.g. CTL+`) and that is the actual bash prompt from your server that has loaded your '.bashrc' profile with @khalidx nifty 'sudocode' command shortcut that under the covers invokes sudoedit in your terminal session and tells it to use vscode (running on the linux host) as your editor. 'sudoedit' is running on the server, not from your workstation.

Thanks for clarifying it. I can see why he was so impressed with his own answer. I would be, it's damn clever. Now all I need is a way to allow vscode to browse the file system in folders that need elevation instead of using sudo at a bash prompt.

[Sieboldianus]

A workaround for me was to add the ssh user to the file-owner's group, e.g. sudo usermod -a -G examplegroup sshuser && su sshuser, then use sudo chmod g+w to allow editing by group members for selected folders. (the su sshuser will make sure groups are refreshed for the current session).

[mjnks]

A workaround for me was to add the ssh user to the file-owner's group, e.g. sudo usermod -a -G examplegroup sshuser && su sshuser, then use sudo chmod g+w to allow editing by group members for selected folders. (the su sshuser will make sure groups are refreshed for the current session).

@Sieboldianus, while this does work, it opens a security vulnerability for any file owned by root. Many of us trying to find a solution are wanting to use the sudo command to allow temporary, limited access to a protected file. If another user is added to the root group (which is the group associated with all the files owned by the root user) then that user essentially becomes the root user. Now, anyone who can compromise that user, can compromise the entire system. A similar vulnerability is introduced when doing this across any other set of users. It is essentially removing (or weakening) a security barrier.

Instead, it would be preferable (and much more secure) to have the ability to run something like sudo code file-owned-by-root while leaving the permissions of that file untainted, and keeping the root user/group locked down and isolated. @khalidx's solution is a pretty close workaround that leaves existing security measures intact.

Though, I am still hoping this capability will become native at some point.