Keep Terminal State with Hermes Persistent Shell

A normal terminal backend can start a fresh subprocess for every command. Persistent shell keeps one long-lived Bash process so the working directory, exported variables, and shell variables survive between calls. It is especially useful over SSH because it also removes repeated connection setup.

terminal:
  persistent_shell: true

Hermes documents persistent shell as enabled by default for SSH and disabled for the local backend. Disable the shared setting with:

hermes config set terminal.persistent_shell false

Know what persists

State that can carry forward includes:

cd changes;
exported environment variables;
ordinary shell variables.

Commands requiring stdin_data or sudo fall back to a one-shot process because the persistent process uses standard input for its own protocol. Do not assume those commands mutate the persistent shell state.

Backend-specific environment values have higher precedence:

TERMINAL_SSH_PERSISTENT overrides SSH behavior;
TERMINAL_LOCAL_PERSISTENT overrides local behavior;
the shared config supplies the baseline.

Use persistent state intentionally

Establish the backend and working directory.
Export only non-secret session values that truly need to persist.
Keep activation commands visible and reproducible.
Avoid relying on invisible shell state in scripts that another operator must run.
Reset or start a fresh session after state becomes ambiguous.

Persistent state can improve performance, but it can also make a later command depend on an earlier hidden assumption.

Checklist

The active terminal backend is known.
Persistence is actually needed for latency or state.
Sensitive values are not printed or embedded in shared logs.
One-shot fallback commands are not expected to alter persistent state.
Verification checks state across two separate terminal calls.
Automation remains reproducible from a clean shell.

Common pitfalls

Assuming local persistence follows the shared default. The documented local override defaults to false.
Expecting sudo state to carry back. That command may run one-shot.
Accumulating stale variables. Long-lived shells can preserve obsolete configuration.
Turning an interactive convenience into a deployment dependency. Production scripts should declare their environment explicitly.

Verification

In a disposable directory, enable persistence for the chosen backend. Run one call that changes directory and exports a harmless variable, then a second call that prints the directory and variable. Confirm both persisted. Run a command that requires one-shot handling and verify your workflow does not depend on its state carrying back.

Official reference: Hermes terminal configuration.