Here's what I recommend (assumes you are using Server Manager extension as well; can be done without it but you'll have to edit JSON in a file):

  1. In Server Manager's tree, expand the namespaces of your server.
  2. Clock the "eye" icon on the %SYS row. This will add another root folder to your VS Code workspace. The folder uses the `isfs-readonly` scheme to access the namespace directly.
  3. In VS Code's Explorer (not ObjectScript Explorer), expand that folder and drill down to find the class you want.

Assuming you want to use this multi-root workspace again, use "Save Workspace As..." from the File menu. If you don't, you'll be prompted when you exit VS Code and given a choice of saving or discarding.

Good video. One tip I have is that at 4:18 it advises using a command to add second and subsequent folders to a multi-root workspace. Instead I recommend clicking on the InterSystems Tools icon in the Activity Bar, then using the Servers tree (contributed by the Server Manager extension) to find your server and namespace, then clicking the pencil button (Edit Code in Namespace). This adds an isfs entry to your workspace. The eye button alongside it will add an isfs-readonly entry instead.

Indeed you can do the whole of the workspace creation from that tree. With nothing open in VS Code (no folder, no workspace) click all the pencils or eyes you want. To name and save your workspace use "Save Workspace As..." from the File menu. If you haven't done that by the time you close the VS Code window you will be prompted to save or discard the as-yet-untitled workspace. So if you just wanted to browse a server speculatively you can use an untitled workspace and discard it when you exit.
 

Instead of adding the %All role to the /terminalsocket web app I suggest you add %DB_IRISLIB which should be sufficient to solve your issue.

My guess is, this environment used to give public %DB_IRISLIB:R but then someone tightened security by removing this, around the time you upgraded WebTerminal.

Such a change ought to show up in the audit log.

UnknownUser is normal for the /terminalsocket session.

Does the problem also occur if you start from an incognito/InPrivate instance of your web browser?

Previously you reported that WebTerminal is working OK on another of your InterSystems environments. Is this still the case? Is that one using 4.9.5 yet?

For the one that fails to make the websocket connection I suggest you use F12 in your browser to open Developer Tools, and make sure network tracing is active before you go to the /terminal/ URL to open a WebTerminal. Look at the network trace messages, and compare them to equivalent messages from a different web browser session that connects successfully to WebTerminal on your other environment.

I'm not clear whether WebTerminal ever worked on this InterSystems instance, e.g. with WebTerminal 4.9.3.

Maybe also worth checking what the InterSystems security audit log is showing around the time you fail to connect with WebTerminal. You may need to turn this auditing on, and perhaps enable it for some additional event types.

As long as the XML import compiled the classes, there's nothing else you need to do in order to benefit from the update.

I suggest you stop using WebTerminal for at least 15 minutes, then check in Portal's Web Sessions page (under System Operation) that no /terminalsocket sessions remain.

Next, launch a WebTerminal. Confirm it reports being version 4.9.5. Check that the Web Sessions page shows one /terminalsocket entry. Now close your WebTerminal browser. Refresh the Web Sessions page. The /terminalsocket entry should no longer be there.