The 'workflow opened terminal' keeps opening panes to the same server

[Gerard]

I recently started using Alfred and added the workflow https://github.com/deanishe/alfred-ssh/ combined with iTerm. All works like a charm, except I found a glitch and can not determine the exact origin.

Normal behavior
When I open an iTerm terminal and login in with SSH to a server, the key combi <cmd>+<d> opens another pane in the same iTerm window but with a local shell prompt. When logging in to a remote server and closing the remote ssh connection, it gives me back my local prompt.

iTerm window opened via workflow
When I open a second pane in the window that was opened via Alfred > SSH workflow, a second pane forces an immediate  login to the same remote server. Closing the ssh connection also immediately closes the pane.
 

Since I often have several panes open to different remote servers this is not preferred. Is this a workflow issue or a misconfiguration in iTerm?

Thanks all!

[deanishe]

Hi @Gerard, welcome to the forum.

 

When you have a question about a specific workflow, please ask in its own thread instead of creating a new one:

 

https://www.alfredforum.com/topic/8956-secure-shell-for-alfred-3-ssh-plus-sftp-mosh-ping-with-autosuggest/?tab=comments#comment-44481

 

To answer your question: it’s iTerm’s doing. The workflow simply asks macOS to open an ssh:// URL.

 

It has no influence over which application receives the URL, nor how it handles it. It certainly doesn’t tell iTerm how its shortcuts should behave.

 

I suspect you have iTerm configured to open new shells with the same working directory as the active one.

Edited October 25, 2020 by deanishe

[Gerard]

Dear @deanishe.

Thanks for the reply, and the useful info. I'll post under the suggested thread next time.

For the people, curious how to fix it. Setting a global shortcut key in iTerm with the default key setting opens the new pane with the default profile (detached or reset if you will, from the current remote ssh session). (See image).

 

Regards,

Gerard.