Native settings sync

[pwoolvett]

Hi. Since native sync is available upstream, is there motivation to implement this? maybe choosing a different "backend" (eg github gists, a la settings sync ext

[code-asher]

I'd like to get it working but I'm unsure if it's possible. Will need to investigate. Related: https://github.com/cdr/code-server/discussions/2064

[Stradivario]

I can help with this feature also.

[code-asher]

Help is definitely welcome!

[csaska]

Settings Sync by Shan Khan seems like a fine alternative for now.

However, it does not appear to work if code-server is used behind a HTTPS reverse proxy. If code-server is running behind a reverse proxy, clicking Login With GitHub will generate a bad URI for the callback as this extension is not aware that it is behind a proxy.

E.g. code-server running on localhost:54321 behind a proxy that is exposed via my.domain.com. Clicking "Login with GitHub" generates http://localhost:54321/callback?code=1234 instead of https://my.domain.com/callback?code=1234

[code-asher]

Oh interesting, I think this might be something that needs to be fixed in the extension itself although I'm not quite sure how. Maybe some kind of redirect URL setting.

[csaska]

Yea definitely a problem with the extension. I just wanted to comment here to link the two issues together.

If the following headers are set by the proxy, and the extension has access to the original request received from code-server, it should be able to generate a valid URI.

E.g.

      proxy_set_header   Host                 $host;
      proxy_set_header   X-Real-IP            $remote_addr;
      proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
      proxy_set_header   X-Forwarded-Proto    $scheme;
      proxy_set_header   X-Forwarded-Prefix   /prefix/if/there/is/one;

I am completely naive to how code-server sends requests to VS Code and what the extension has access to.

[chilcano]

I solved this issue with this workaround. https://github.com/shanalikhan/code-settings-sync/issues/1236#issuecomment-759538307 Hope it helps.

[Yrobot]

Hope native settings sync will work in the future.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.

[prokher]

It still would be nice to have it.

[djarbz]

As a workaround, I copied the URL and ran a curl from the code-server terminal window. curl localhost:54321/callback?code=SecretCode

[jsjoeio]

@djarbz and that worked for you?

[djarbz]

Yes, for shanalikhan/code-settings-sync. This extension is listening on port 54321 and is just looking for the secret code to come through as a query.

[nghminh163]

Actually, u can enable native settings but u need to get config from your local vscode and patch it to code-server. I enabled and patch my code server version with vscode config so I can get ext from vscode official like Copilot and using sync with my Github Account

[djarbz]

@nghminh163 can you elaborate on the steps needed for this?

[nghminh163]

Actually, in this week I will make new fork for adaptive with my patch. I will ping here again with my document

[jmqm]

Actually, in this week I will make new fork for adaptive with my patch. I will ping here again with my document

[edqx]

Any updates on this in the new year? It might be the one thing stopping me from really using Coder properly as I used GitHub codespaces.

[code-asher]

No updates. I think it is unlikely this will get worked on from our end any time soon (possibly never).

[qraynaud]

@nghminh163 you seemed to have a solution? Is this any good?

[bordernone]

Actually, in this week I will make new fork for adaptive with my patch. I will ping here again with my document

any update?

[davidcomputes]

No updates. I think it is unlikely this will get worked on from our end any time soon (possibly never).

Too complicated, not enough demand, or both? It'd be a very helpful update.

[code-asher]

I think both. Our main use for code-server is through https://github.com/coder/coder and there you can do things like automatically cloning settings via a personal dotfiles repository so there is no demand from that side of things.

Cloning a settings repository seems like a fairly reasonable workaround that can be automated outside of coder/coder as well.

I have not seen any of the native sync code or how much will need to be implemented so the complexity is a big unknown but I doubt it will be trivial.

Lastly, it is unclear to me whether there is a significant enough advantage this would have over just using a settings sync extension anyway.

That said, PRs are welcome, and I will bring up the issue during the next sprint planning as it would help to further differentiate code-server from other OSS builds of VS Code.

Or, if there is enough support maybe even Microsoft will consider making settings sync available for OSS builds (but I would not bet on it).

https://github.com/microsoft/vscode/issues/110668

[edqx]

Just for a grasp of what is actually required: I'm assuming it isn't reasonable to use the same database that Visual Studio uses (i.e., by using some undocumented API), so I'm guessing that the only way forward for proper "settings sync" between clients is to make it an extension, possibly pre-installed. This isn't "native" obviously but it's better than nothing.

It could be built into the editor (native), but I don't think this helps considering you'd need to install an extension on non-Coder instances of Visual Studio Code to actually import your settings from. Alternatively, it might just be a neat thing standalone that every Coder Visual Studio Code instance under your user (for each of your projects) has the same settings. In this way it could be native.

The extension https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync&ssr=false#overview, I've found, is very sub-par and I've had very little success with it; I've found it easier just to install the extensions that I need manually.

Willing to PR if we can figure out the requirements exactly here.

[code-asher]

I'm assuming it isn't reasonable to use the same database that Visual Studio uses (i.e., by using some undocumented API)

Yeah from what I recall this would be a violation of their API's terms of service.

It could be built into the editor (native), but I don't think this helps considering you'd need to install an extension on non-Coder instances of Visual Studio Code to actually import your settings from.

Good point! An extension might be the way to go.

Although, I suppose one other path forward is to re-implement the settings sync API backend as a standalone binary you can self-host which would allow us to re-use all the client-side sync code by just patching it to point to a user-configurable endpoint (pretty much exactly what we do for the marketplace).

But...like you said then we would need an extension anyway for non-Coder VS Code...unless it is possible to configure the sync endpoint already?

And maybe people prefer a non-self-hosted backend like gists or something anyway. Would be curious to hear thoughts.

Willing to PR if we can figure out the requirements exactly here.

Thank you!

If we go with an extension it might make sense to use a standalone repository rather than maintaining it here because I think that might make it easier for folks to contribute, especially for those that might want to use this in other OSS builds of VS Code like VSCodium.

[edqx]

Thanks for the responses!

Re-implementing the settings sync API sounds fun! 🙂 That could be a decent project, could use the opportunity to learn some Rust finally (I know... late bloomer). I think an extension for non-coder VS Code would be fairly light-weight in this situation - it would just be a matter of somehow redirecting the default settings sync API back-end to the user configured one. If that's not possible, then most of the code for settings sync things is freely available anyway.

I'll wait to hear some thoughts on using something like Gist VS a private settings sync instance before going further though. I will say that going the back-end route is likely more helpful for me personally.

[kimtiago]

Use this extension, it's working

https://marketplace.visualstudio.com/items?itemName=nonoroazoro.syncing

[Ali-Flt]

I used nonoroazoro.syncing and it broke my extensions after I changed from a browser to another (some extensions were removed, had to reinstall them). Maybe I did something wrong but I don't think so. I do not recommend using it

[kimtiago]

I used nonoroazoro.syncing and it broke my extensions after I changed from a browser to another (some extensions were removed, had to reinstall them). Maybe I did something wrong but I don't think so. I do not recommend using it

Maybe you must observe this at the end of Getting Started session:

Frequently Asked Questions How do I make this work with code-server?

Code-server follows the XDG spec to set config & data directories. When using their Docker image, you can set XDG_DATA_HOME="/home/coder/.config/" to store everything files in the same directory. This enables vscode-syncing to easily pickup the right locations. Since it is also a recommended volume path, it ensures persistence of your changes.

[Ali-Flt]

Maybe you must observe this at the end of Getting Started session:

Interesting.. I am not using the docker image though. Is this also achievable with the code-server cli? The cli accepts --user-data-dir and --extensions-dir. Is setting these two arguments to the same directory the same as using XDG_DATA_HOME? Also I tried setting the XDG_DATA_HOME environment variable and then running the code-server but it didn't work:

Do you know where I can find the dockerfile of the code-server Docker image?

[kimtiago]

i don't know, i use docker and this tip fixed my problem...

you can ask for help here https://github.com/nonoroazoro/vscode-syncing

[code-asher]

Our Docker image is built with this Dockerfile: https://github.com/coder/code-server/blob/main/ci/release-image/Dockerfile

By default code-server uses XDG_DATA_HOME for --user-data-dir and uses a directory called extensions inside the --user-data-dir directory.

So, it is equivalent to set either XDG_DATA_HOME or --user-data-dir and there is no need to set --extensions-dir unless you want it separate from the data directory.

In your screenshot you would need to export the XDG_DATA_HOME environment variable to make it available to sub-processes. Without export it is only set in the current process.

[Ali-Flt]

@code-asher oh I did not know that export has that functionality😅 Thanks