Store state on remote instead of browser

@code-asher

Edit by @code-asher: Storing the state in the browser has (at least) the two following problems:

If you switch to another browser you have to open and configure everything all over again (what this issue was originally about).
It is impossible to seed the initial state like you could in native VS Code by writing to the JSON state file.

Original issue content follows.

OS/Web Information

Web Browser: Chrome v91
Local OS: Windows 10
Remote OS: Ubuntu 20.04
Remote Architecture: Debian
code-server --version: 3.12.0

Steps to Reproduce

Open a new code server instance in browser and make some changes (eg : hide remote host).
Open the same instance in incognito tab.
The changed made above will not be reflected, and you have to make those changes again.

Expected

Till v3.11 the state of code-server was maintained across browsers.

Actual

The state is saved local storage instead of server and hence the changes does not reflect on browser changes.

Notes

scope === StorageScope.GLOBAL ? 'global' : this.payload.id; it is in workbench.web.api.js.map
Perhaps it's related to where the state is saved?
From discussion : #4185

@abhay-ranawat

Thanks for opening this up @abhay-ranawat! We'll have to investigate

I have the same issue.

It would be great to have this resolved with v3.12.1.

It would be great to have this resolved with v3.12.1.

That's unlikely to happen given our bandwidth (just setting expectations) but at least we know multiple folks are experiencing this issue.

It would be great to have this resolved with v3.12.1.

That's unlikely to happen given our bandwidth (just setting expectations) but at least we know multiple folks are experiencing this issue.

Given the changes made in code, everyone should face it (AFAIK) only few might be noticing it.

Agreed. I noticed it because I regularly delete all cookies and site data that the browser stores. I don't mind setting an exception for the domains on which code-server is deployed, though.

It doesn't matter whether the state is stored in ~/.local/share/code-server/User/state or the browser 's site data - but it should be documented, which is the case.
👉 In order to reset the state, one has to either delete ~/.local/share/code-server/User/state or clear the browser's site data.

ℹ️ I had to delete folder ~/.local/share/code-server/User/state after I moved from debian:buster to debian:bullseye, because e.g. the new Python version was not displayed correctly in v3.10.2.

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.

As for stale bot see https://drewdevault.com/2021/10/26/stalebot.html: This is a terrible, horrible, no good, very bad idea.

https://drewdevault.com/2021/10/26/stalebot.html

That was a great read. In the past we would periodically run through old issues and close out ones that no longer were applicable (this is because things can change a lot when we update Code versions) and the stale bot moves that burden off us to those who opened the issue. We could just leave them alone but we felt like keeping issues up to date was part of good repository maintenance. Maybe there is a better solution, like labeling issues that are on the Code side with something like upstream and then adding stale or revalidate or something to those when we update Code?

For the browser state I did look into moving it back to the remote file system but it looked non-trivial so I abandoned that effort since we generally try to avoid patches that deviate too aggressively from mainline.

There might be a clean way to do it with a bit more investigation though or maybe upstream would be receptive of a change to make this behavior configurable.

Delete local storage patch

@alessandrodd

When using Roo Code, settings are lost between browser sessions. @alessandrodd's PR appears to allow some settings to be saved. However, since this PR does not cover SecretStorage, API keys still cannot be persisted.

Gemini suggests using the --password-store=basic option. However, code-server does not support this option. Could enabling the --password-store option serve as a temporary workaround?

In vscode/src/vs/workbench/services/secrets/browser/secretStorageService.ts, there is

// We don't have encryption in the browser so instead we use the
// in-memory base class implementation instead.
super(true, storageService, encryptionService, logService);

Does this mean code-server always keeps secrets in memory?

It is supposed to store secrets in browser storage, or at least it used to last I checked.

It looks like while that is the base class, there is the secretStorageProvider below that can still be used to store secrets, and that is set here as long as there is a secret key path: https://github.com/microsoft/vscode/blob/ce099c1ed25d9eb3076c11e4a280f3eb52b4fbeb/src/vs/code/browser/workbench/workbench.ts#L619-L621

secretStorageProvider: config.remoteAuthority && !secretStorageKeyPath
  ? undefined /* with a remote without embedder-preferred storage, store on the remote */
  : new LocalStorageSecretStorageProvider(secretStorageCrypto),

We patch the secret key path to be /mint-key so in theory this should mean the keys are persisted, I think, but perhaps there is more to the story.

After applying alessandrodd's PR and the following patch, the secrets are stored on the server side.

The patch is generated by AI. I have no idea if this is a "dirty" hack.

To those who want to give it a try: please note that the secrets are stored unencrypted in $HOME/.local/share/code-server/User/globalStorage/state.vscdb.

Index: code-server/lib/vscode/src/vs/platform/secrets/common/secrets.ts
===================================================================
--- code-server.orig/lib/vscode/src/vs/platform/secrets/common/secrets.ts
+++ code-server/lib/vscode/src/vs/platform/secrets/common/secrets.ts
@@ -77,8 +77,8 @@ export class BaseSecretStorageService ex
 
 			try {
 				this._logService.trace('[secrets] decrypting gotten secret for key:', fullKey);
-				// If the storage service is in-memory, we don't need to decrypt
-				const result = this._type === 'in-memory'
+				// Don't decrypt if storage is in-memory or if encryption service is not available
+				const result = this._type === 'in-memory' || !await this._encryptionService.isEncryptionAvailable()
 					? encrypted
 					: await this._encryptionService.decrypt(encrypted);
 				this._logService.trace('[secrets] decrypted secret for key:', fullKey);
@@ -98,8 +98,8 @@ export class BaseSecretStorageService ex
 			this._logService.trace('[secrets] encrypting secret for key:', key);
 			let encrypted;
 			try {
-				// If the storage service is in-memory, we don't need to encrypt
-				encrypted = this._type === 'in-memory'
+				// Don't encrypt if storage is in-memory or if encryption service is not available
+				encrypted = this._type === 'in-memory' || !await this._encryptionService.isEncryptionAvailable()
 					? value
 					: await this._encryptionService.encrypt(value);
 			} catch (e) {
@@ -136,8 +136,9 @@ export class BaseSecretStorageService ex
 
 	private async initialize(): Promise<IStorageService> {
 		let storageService;
-		if (!this._useInMemoryStorage && await this._encryptionService.isEncryptionAvailable()) {
-			this._logService.trace(`[SecretStorageService] Encryption is available, using persisted storage`);
+		if (!this._useInMemoryStorage) {
+			// Use persisted storage when not forced to use in-memory
+			this._logService.trace(`[SecretStorageService] Using persisted storage`);
 			this._type = 'persisted';
 			storageService = this._storageService;
 		} else {
@@ -145,7 +146,7 @@ export class BaseSecretStorageService ex
 			if (this._type === 'in-memory') {
 				return this._storageService;
 			}
-			this._logService.trace('[SecretStorageService] Encryption is not available, falling back to in-memory storage');
+			this._logService.trace('[SecretStorageService] Falling back to in-memory storage');
 			this._type = 'in-memory';
 			storageService = this._register(new InMemoryStorageService());
 		}
Index: code-server/lib/vscode/src/vs/workbench/services/secrets/browser/secretStorageService.ts
===================================================================
--- code-server.orig/lib/vscode/src/vs/workbench/services/secrets/browser/secretStorageService.ts
+++ code-server/lib/vscode/src/vs/workbench/services/secrets/browser/secretStorageService.ts
@@ -22,9 +22,9 @@ export class BrowserSecretStorageService
 		@IBrowserWorkbenchEnvironmentService environmentService: IBrowserWorkbenchEnvironmentService,
 		@ILogService logService: ILogService
 	) {
-		// We don't have encryption in the browser so instead we use the
-		// in-memory base class implementation instead.
-		super(true, storageService, encryptionService, logService);
+		// Use remote storage if enabled, otherwise use in-memory storage
+		const useRemoteStorage = environmentService.options?.remoteStorageEnabled ?? false;
+		super(!useRemoteStorage, storageService, encryptionService, logService);
 
 		if (environmentService.options?.secretStorageProvider) {
 			this._secretStorageProvider = environmentService.options.secretStorageProvider;
Index: code-server/lib/vscode/src/vs/code/browser/workbench/workbench.ts
===================================================================
--- code-server.orig/lib/vscode/src/vs/code/browser/workbench/workbench.ts
+++ code-server/lib/vscode/src/vs/code/browser/workbench/workbench.ts
@@ -640,8 +640,8 @@ class WorkspaceProvider implements IWork
 				})
 			}
 		},
-		secretStorageProvider: config.remoteAuthority && !secretStorageKeyPath
-			? undefined /* with a remote without embedder-preferred storage, store on the remote */
+		secretStorageProvider: config.remoteStorageEnabled || (config.remoteAuthority && !secretStorageKeyPath)
+			? undefined /* with remote storage, or with no embedder-prefered storage, store on the remote */
 			: new LocalStorageSecretStorageProvider(secretStorageCrypto),
 	});
 })();

remote-secret-storage.patch

@hefanbo

@hefanbo I think the PR link in your comment is broken. Should it be microsoft/vscode#288880 ?

@hefanbo I think the PR link in your comment is broken. Should it be microsoft/vscode#288880 ?

Fixed. Thanks!

@hefanbo

@hefanbo Can I bother you for build instructions?
I have been trying to use your patch with alessandro's PR but I think I'm getting a mismatch between vscode versions and code-server versions.
Do you remember which version of code-server you aligned with alessandro's PR and your patch?

@oransterf

@oransterf

Please try the following patch on 44fc463

I applied some other patches before this one, so there might be offsets when you apply it.

remote-storage.patch

I'm getting rejected chunks trying to apply this patch too. Any chance you'd want to host your proof of concept branch in your own fork for frame of reference?

I'm getting rejected chunks trying to apply this patch too. Any chance you'd want to host your proof of concept branch in your own fork for frame of reference?

same here, I tried getting as close as I could but no avail.
I tried running alessandro's PR to just use vscode web but some things were still stored in the browser session (user settings, etc)

would appreciate a full branch of your fork or a dockerfile!

I'm on vacation now and will be back in a few days with my fork.

@echuber2

Please try my fork @echuber2 @oransterf

It worked, thank you so much!

fix: persist workbench state on the remote

Navigation Menu

Repository navigation

Store state on remote instead of browser #4212

OS/Web Information

Steps to Reproduce

Expected

Actual

Notes

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Store state on remote instead of browser #4212

Description

OS/Web Information

Steps to Reproduce

Expected

Actual

Notes

Activity

jsjoeio commented on Sep 21, 2021

benz0li commented on Sep 24, 2021

jsjoeio commented on Sep 24, 2021

abhay-ranawat commented on Sep 24, 2021

benz0li commented on Oct 6, 2021

stale commented on Apr 4, 2022

benz0li commented on Apr 4, 2022

code-asher commented on Apr 11, 2022

22 remaining items

hefanbo commented on Mar 23, 2026

hefanbo commented on Mar 23, 2026

code-asher commented on Mar 23, 2026

hefanbo commented on Mar 24, 2026

echuber2 commented on Mar 24, 2026

hefanbo commented on Mar 24, 2026

oransterf commented on Apr 25, 2026

hefanbo commented on Apr 27, 2026

echuber2 commented on May 1, 2026

oransterf commented on May 1, 2026

hefanbo commented on May 2, 2026

hefanbo commented on May 6, 2026

oransterf commented on May 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions