We now support transferring additional workspace-specific state beyond uncommitted changes in a Continue Working On transition, e.g. from web to a local clone but for the same repository like microsoft/vscode (ref #179898). This allows us to provide continuity when a user needs to work on the same repo while transitioning across different development environments.

Ask: We generally want to transfer any state that is user-generated and ephemeral, such as user queries and drafted changes. Not all state needs to be transferred, and I've compiled an initial list that could make sense to adopt this for below. If I missed any or if you have any questions, please reach out.

Area owners:

• Notebook controller affinity @rebornix
• Find history within an editor @rebornix
• Source control commit message history @joaomoreno
• Pending comments @alexr00
• Text search history @andreamah
• Breakpoints @roblourens @connor4312
• Open editors @bpasero

Details: Your component can opt into this by using the IStorageService under the StorageScope.WORKSPACE and StorageTarget.USER combination to store and retrieve state based on onWillSaveState and onDidChangeValue, e.g.

// in environment A e.g. github.dev
this.storageService.onWillSaveState(() => {
    // no need to serialize objects before storing
    const myObj = { resourceUri };
    this.storageService.store('myKey', myObj, StorageScope.WORKSPACE, StorageTarget.USER);
})

// in environment B e.g. desktop clone of repo
this.storageService.onDidChangeValue((v) => {
    if (v.key === 'myKey') {
        const restoredObj = this.storageService.getObject('myKey', StorageScope.WORKSPACE);
        // apply restored state for your component
    }
});

Any URIs in your stored object values that originated in another instance of VS Code but for the same workspace, e.g. vscode-vfs to file, will be automatically converted for you (if a conversion is possible) before onDidChangeValue is emitted.

Note: The key that you use to retrieve your state should not include non-portable data like URI paths or serialized URIs, since keys will not be automatically converted.

If you have any state already in the workspace and the restored state might step on it, as much as possible your component should try to merge that state (e.g. append new history to existing history) without showing the user a confirmation UI, since the goal is to provide a seamless transition. Again please reach out if this is infeasible.