If the user I authenticate with doesn't have USE permission on %Service_Login you don't even try, which means I get a terminal session with the username and roles (typically %All) of the account IRIS runs as.

I have raised https://github.com/caretdev/iterm/issues/2 about this.

What about if you are logged into Linux as the userid which your IRIS runs as? On a default install it's typically irisusr, and on the containerized IRIS instances @Dmitry Maslennikov probably uses it's typically irisowner.

Here's what I find when I successfully connect to a Docker container created from a DC registry image, authenticating as SuperUser/SYS

Node: d2ba2ec8dbce, Instance: IRIS

USER>w $zv
IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2024.1 (Build 262U) Thu Mar 7 2024 15:36:40 EST
USER>w $username
SuperUser
USER>!whoami
irisowner

USER>

@Jeffrey Drumm I think your issue is likely to be that the app apparently assumes this OS-level command will lead directly to an IRIS shell prompt without requiring credentials. On Linux this means the %Service_Terminal service is accepting Operating System authentication. There must also be an IRIS user definition that matches the OS username under which IRIS runs, and that user must have sufficient rights. Enabling login-related audit messages may help you diagnose failures in this area:

/path/to/iris/bin/irisdb -s/path/to/iris/mgr

Are you able to launch an IRIS Lite Terminal onto this server from inside VS Code? Testing  this could rule out it being an issue with websockets.

@Jeffrey Drumm does this also happen if you launch iterm from a private browser session?

Probably has no hope of working on Windows:

Browser devtools network trace shows this repeatedly:

oops: <PYTHON EXCEPTION> 246 <class 'ModuleNotFoundError'>: No module named 'termios'

@Evgeny Shvarov re #3 when you write git-source-control are you referring to this package?

https://openexchange.intersystems.com/package/Git-for-Shared-Developmen…

Is using this with the client-side paradigm a supported mode? I haven't yet found any documentation to that effect.

@Evgeny Shvarov  re #1 aren't you already using the "objectscript.conn.docker-compose.service" and ""objectscript.conn.docker-compose.internalPort" settings? If you're finding a specific problem using these please open an issue at https://github.com/intersystems-community/vscode-objectscript/issues

Since the Cody people talk about "the repository" I'm guessing they mean a local Git repository. When you're using ISFS you're using the server-side editing paradigm, so no local Git repository is involved.

The missing `set` was because I had copied the wrong line from my shell session. I have edited the post to correct this.

I get the same as Jeff, so it seems the zpm install installed the requirements OK.

Thanks for adding the BYOP doc to the wiki.

Pinging @Semion Makarov in case the extra point has been overlooked.
 

...and Jetpack now has a video plus a first DC article.

Here's a technique I previously wrote up, maybe useful until IPM supports this scenario itself.

https://community.intersystems.com/post/can-zpm-ipm-package-be-required…

No, nothing else new in it. Were you able to connect but not work? Or wasn't it possible to connect? If the latter, perhaps the server had run out of licenses.