Summary
On macOS, newly opened sessions in the official cloudcli-plugin-terminal start in bash, even when the user's real login shell is zsh.
Environment
- CloudCLI:
1.29.0
- Plugin:
cloudcli-plugin-terminal 1.0.1
- Platform: macOS arm64
What I observed
- Opening a new Terminal tab starts in
bash.
- The shell then suggests switching to
zsh.
- After switching manually, the next newly opened tab still starts in
bash again.
Root cause
The plugin server chooses the shell using:
process.env.SHELL || '/bin/bash'
But CloudCLI starts plugin backend processes with a deliberately restricted environment and does not pass through SHELL.
That restricted environment looks intentional and should probably remain restricted for safety. However, for the terminal plugin specifically, it means the plugin falls back to /bin/bash even when the user's actual login shell is zsh.
Expected behavior
On macOS, if the plugin backend only has a stale or missing SHELL, newly created terminal sessions should still start in the user's real login shell.
Suggested fix
Keep the host/plugin restricted environment model unchanged, but add a terminal-plugin-local compensation:
- on
darwin only
- if
process.env.SHELL is missing or still /bin/bash
- fall back to
os.userInfo().shell
- pass the resolved shell into the PTY child env as
SHELL, so the shell session is internally consistent
This avoids broadening the host plugin environment while still fixing the terminal UX.
Summary
On macOS, newly opened sessions in the official
cloudcli-plugin-terminalstart inbash, even when the user's real login shell iszsh.Environment
1.29.0cloudcli-plugin-terminal1.0.1What I observed
bash.zsh.bashagain.Root cause
The plugin server chooses the shell using:
process.env.SHELL || '/bin/bash'But CloudCLI starts plugin backend processes with a deliberately restricted environment and does not pass through
SHELL.That restricted environment looks intentional and should probably remain restricted for safety. However, for the terminal plugin specifically, it means the plugin falls back to
/bin/basheven when the user's actual login shell iszsh.Expected behavior
On macOS, if the plugin backend only has a stale or missing
SHELL, newly created terminal sessions should still start in the user's real login shell.Suggested fix
Keep the host/plugin restricted environment model unchanged, but add a terminal-plugin-local compensation:
darwinonlyprocess.env.SHELLis missing or still/bin/bashos.userInfo().shellSHELL, so the shell session is internally consistentThis avoids broadening the host plugin environment while still fixing the terminal UX.