compatibility: remote command execution assumes bash-based login shells on target systems

[richard950825-sys]

Summary

Hermes Gate currently wraps remote commands through bash -l -c ... and also launches remote Hermes sessions with bash -l -c hermes.

This is a portability bug because it assumes the remote system has a compatible bash available in the expected way.

Current behavior

Remote command helpers are currently defined around:

return f"bash -l -c {shlex.quote(command)}"

and session creation uses:

tmux new-session -d -s <name> "bash -l -c hermes"

Why this matters

Not all target machines that can run Hermes Gate workflows will satisfy this assumption.

Common failure environments include:

• Alpine / BusyBox-style systems
• minimal containers
• hardened or enterprise hosts where login shells differ
• systems where bash is absent or not on the expected path

The tool should not unnecessarily fail on systems that otherwise support SSH, tmux, and the target runtime.

Evidence

Observed in:

• hermes_gate/session.py:109-120
• hermes_gate/session.py:187-189
• hermes_gate/app.py:644-669 for attach-time tmux command wrapping

Expected behavior

Remote execution should either:

• use a more portable shell invocation strategy
• detect capabilities explicitly
• or clearly document and enforce a justified platform requirement if bash is truly mandatory

For a general-purpose remote management tool, the preferred direction is broader compatibility rather than hidden shell assumptions.

Suggested direction

Candidate approaches:

• use sh -lc if the command model permits it
• detect remote shell availability before relying on bash-specific behavior
• minimize shell nesting and pass argv in a way that reduces shell-specific coupling
• document any remaining hard requirement precisely if one cannot be avoided

Acceptance criteria

• Hermes Gate no longer assumes bash is available on every target host unless that requirement is made explicit and intentional
• remote list/create/kill/attach helper paths are validated under the new strategy
• error messages for unsupported targets are explicit rather than opaque command failures
• documentation states the actual supported target assumptions

Testing requirements

Automated tests

• unit tests for remote command generation
• regression tests for any shell/capability detection logic introduced

Manual / integration validation

Validate against at least:

1. a normal bash-based target
2. a target where /bin/sh exists but bash does not
3. a target with tmux installed but different login-shell behavior

For each case, verify list/create/kill/attach behavior or verify that failures are explicit and documented.

Non-goals

• keeping the bash requirement implicit and only reacting after user bug reports
• solving only one code path while other remote helpers still hard-code bash -l -c