Clarification Needed: "Proxmox VE Shell" Definition

[ggfevans]

Core Issue: The "run only in the Proxmox VE Shell" warning appears designed to ensure environmental consistency for scripts, but it's unclear whether SSH + tmux can provide that consistent environment, or if there's a way to invoke one of the four known-good shell options from an SSH session.

The Ambiguity

Your README says: "Open the Proxmox shell on your main node and paste the command."

But scripts warn: "run the command below only in the Proxmox VE Shell"

The Proxmox Web UI offers four shell options:

• Shell (standard terminal)
• noVNC (remote console)
• SPICE (remote protocol)
• xterm.js (web-based terminal)

Question: Can these shell environments be accessed or invoked from an SSH + tmux session on the Proxmox host itself, or is SSH fundamentally incompatible with the intended execution environment?

What I've Found

Based on discussion comments in similar threads (e.g., [this discussion](#7738 (reply in thread))), the "Proxmox VE Shell" validation appears to check whether SSH_CLIENT is null in the session environment.

If this is the actual check, it suggests the warning is designed to ensure scripts run in the intended execution context—likely the Web UI shell interfaces (Shell, xterm.js, noVNC, SPICE)—rather than in a remote SSH connection.

However, this creates a practical question: If I SSH into the Proxmox host itself (not remote execution), can I access one of these four shell environments from my terminal?

For example, is there a CLI method or tool that would let me:

# SSH into Proxmox host
ssh root@pve-host

# Then access one of the shell interfaces?
pve-shell --method=xterm.js
# or
pve-terminal
# or some other mechanism

Or, if these shell interfaces are only accessible through the Web UI:

# SSH + tmux session
ssh root@pve-host
tmux new-session -s pve-work

# Then tunneling into the Web UI shell?
ssh -L 8006:localhost:8006 root@pve-host  # then browser to http://localhost:8006?

The core question: Is there an official way to access the intended shell environment from SSH + tmux, or is this fundamentally a Web UI-only feature?

My Questions

1. Is the warning designed to ensure a specific execution environment (Web UI shell interfaces)?

If so, is there an official way to access these environments from SSH + tmux, or are they Web UI-only?

2. If SSH + tmux cannot access these shell environments, would directly running scripts via SSH still provide equivalent environmental consistency?

For example, would ssh root@pve-host "bash -c '$(wget -qLO - script.sh)'" provide the same consistent environment as the Web UI, even if technically executed over SSH?

3. What specific environmental variables, PATH settings, or configurations does the script depend on?

Understanding the "environmental consistency" being enforced would clarify whether SSH + tmux actually fails to provide it, or just approaches it differently.

Why This Matters

Environmental Consistency Matters. If the warning exists to ensure scripts run in a consistent, predictable environment, that's a legitimate concern. Helper scripts might depend on specific variables, PATH configurations, or shell behaviors that only the Web UI provides.

But This Has Practical Implications:

If the warning is only about excluding remote SSH execution (commands run from a different host), that's fine—I wouldn't want to run these scripts remotely either.

But if it's excluding all SSH sessions, that unnecessarily prevents SSH + tmux workflows, which offer real advantages for long-running system scripts (session persistence, disconnection resilience, automation, history preservation).

What Users Need to Know:

• Can I use SSH + tmux safely for these scripts? (Yes/No)
• If no, what specific environment requirements prevent it?
• If yes, what's the recommended SSH-based workflow?

This clarity would help users choose the right approach and contribute more confidently to the project.

This would clarify whether SSH is a viable option or a known limitation, and help users like me understand the reasoning behind the requirement.

[ggfevans]

Interesting discovery—there's also https://github.com/community-scripts/ProxmoxVE-Local which appears to be a purpose-built web app for exactly this use case (no more curl | bash into the Web UI shell). It runs as an LXC container and manages script execution through a Node.js backend with real-time output streaming, which might sidestep the "Proxmox VE Shell" requirement entirely by removing the need to execute scripts in that specific environment.

[michelroegl-brunner]

Yes the Pve-local app works with ssh connections, as otherwise a user would need to install it on everey node. But to get the ssh working correctly it took some fiddeling with settings. I control a seperate version of the backend scripts to get that working correctly.

[ggfevans]

Yes the Pve-local app works with ssh connections, as otherwise a user would need to install it on everey node. But to get the ssh working correctly it took some fiddeling with settings. I control a seperate version of the backend scripts to get that working correctly.

Oh, can you share your approach and what settings you'd use?