Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Not sure. I run "code tunnel" without opening the UI. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.80.0 OS Version: Ubuntu 22.04 LTS Steps to Reproduce: Install VSCode or Code Cli on Ubuntu Desktop 22.04 "code tunnel" on Ubuntu. server license terms and login to and enter the code. tunnel will show: . VSCode tunnel and rerun "code tunnel". It will ask for GitHub authentication again, because it failed to update keyring.
Seems to duplicate the upstream issue on To work around this, you can set the environment variable (e.g. by running and reconnecting). But this seems fairly common, we should automatically use a file keychain if we get this error.
Hi Connor, Thanks for your help! It would be wonderful if the error can be automatically dealt with since many people don't know the environment variable.
yes,
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Putting in a new line in does the trick for me. (putting the env var in a global file ensures that it will be defined regardless of where it's running or who is running it; note that on some systems this may be a massive security hole)
I now see this in insiders: and then when I restart: looks verified to me.

Discussion:
struct StorageWithLastRead { storage: Box<dyn StorageImplementation>, <ins> fallback_storage: Option<FileStorage>, </ins> last_read: Cell<Result<Option<StoredCredential>, WrappedError>>, }

let mut keyring_storage = ThreadKeyringStorage::default(); let mut file_storage = FileStorage(PersistedState::new(self.file_storage_path.clone())); <del> let keyring_storage_result = match std::env::var("VSCODE_CLI_USE_FILE_KEYCHAIN") { Ok(_) => Err(wrap("", "user prefers file storage").into()), _ => keyring_storage.read(), </del> <ins> let native_storage_result = if std::env::var("VSCODE_CLI_USE_FILE_KEYCHAIN").is_ok() || self.file_storage_path.exists() { Err(wrap("", "user prefers file storage").into()) } else { keyring_storage.read() </ins> }; <del> let mut storage = match keyring_storage_result { </del> <ins> let mut storage = match native_storage_result { </ins> Ok(v) => StorageWithLastRead { last_read: Cell::new(Ok(v)), <ins> fallback_storage: Some(file_storage), </ins> storage: Box::new(keyring_storage), }, Err(e) => {

.read() .map_err(|e| wrap(e, "could not read from file storage")), ), <ins> fallback_storage: None, </ins> storage: Box::new(file_storage), } }

"Failed to update keyring with new credentials: {}", e ); <ins> if let Some(fb) = storage.fallback_storage.take() { storage.storage = Box::new(fb); match storage.storage.store(creds.clone()) { Err(e) => { warning!(self.log, "Also failed to update fallback storage: {}", e) } Ok(_) => debug!(self.log, "Updated fallback storage successfully"), } } </ins> } storage.last_read.set(Ok(Some(creds))); }) }