Skip to main content
AutomexiaDocs
Ctrl K

Remote sessions and WSL#

Automexia hosts the command-line tools you already use. OpenSSH owns remote connections and credentials. Linux is the first development focus; Windows-hosted WSL sessions describe platform direction, not verified compatibility.

Connect with OpenSSH#

Run OpenSSH from the shell:

text
ssh host-alias

You can also provide an explicit user and host:

text
ssh user@example.com

OpenSSH remains responsible for keys, agents, certificates, host verification, proxy jumps, ports, and configuration precedence. Automexia hosts the session; it does not replace the SSH security model.

If you normally use a shell alias or function around ssh, it still belongs to that shell. Check what it expands to before relying on it. The current public source also has an explicit +ssh wrapper for optional interactive remote shell integration; ordinary ssh does not need that wrapper, and neither path gives Automexia a credential store.

Keep repeated hosts in OpenSSH config#

For a host you use often, define the alias in your normal OpenSSH configuration and connect with ssh alias. This keeps connection policy in the tool that understands it instead of hiding sensitive details in a terminal shortcut.

For example, a simple entry in your own ~/.ssh/config can give a long host name a short name:

sshconfig
Host staging
    HostName staging.example.com
    User developer

Then type ssh staging in a pane. Replace the example address and user with your approved destination. For a host behind a jump server, OpenSSH's ProxyJump directive belongs in the same config, not in Automexia's theme or shortcut settings. The Connection Hub guide has a two-host example. OpenSSH evaluates the effective configuration; the Hub's static inventory is only a review aid.

Source builds that expose the read-only Connection Hub can help you review aliases from files you explicitly select. See the Connection Hub guide for setup and examples; it does not replace ssh for connecting.

If you want prompt/context support in a compatible remote interactive shell, read Use Automexia +ssh before invoking it. The wrapper calls system OpenSSH and has explicit fallback and opt-in helper boundaries; it is not the Hub's disabled managed Connect action.

Work locally and remotely side by side#

  1. Keep a local shell in one pane.
  2. Open a fresh split.
  3. Run ssh host-alias in the second pane.
  4. Move between panes with the configured pane shortcuts.

A cloned pane copies the local launch context. It does not duplicate an already running remote process.

Keep the selected pane in mind when you type or paste: the terminal sends input to that pane's session. For example, a local build on the left and ssh staging on the right can stay visible together, but an exit typed in the right pane ends only that SSH session.

Transfer files with your installed tools#

Run scp or sftp in a shell when you need to move files. They use your OpenSSH configuration and authentication; Automexia supplies the terminal view, not a file-transfer service. For example:

text
scp ./report.txt staging:~/reports/
sftp staging

Review the local path, remote alias, and destination before transferring. Never treat a displayed filename or a copied command as proof that the remote host is the one you intended. For repeated transfers or synchronization, use the appropriate tool and your organization's policy.

Use port forwarding intentionally#

When you need a local forward, use OpenSSH syntax and review the listening address, destination, and host:

text
ssh -L 8080:localhost:80 host-alias

Follow your organization’s access and network policies. Automexia does not create tunnels in the background.

If you need a jump host, put it in the OpenSSH alias as shown in the Connection Hub guide. Avoid embedding credentials in the command or a saved terminal action.

Use WSL as its own environment#

There is no website package. Running a Linux development build under WSLg is not a verified compatibility claim. The guidance below concerns a future Windows application; see Platform support.

WSL has its own shell, filesystem, tools, profiles, packages, and trust state.

  • Keep Linux build-heavy repositories in the WSL filesystem when performance matters.
  • Keep native Windows toolchains and Windows-only work on NTFS.
  • Configure aliases and profiles separately inside each environment.
  • Use Automexia splits when you need Windows and WSL tools in the same workspace.

Current source can read bounded Kubernetes context from the selected WSL distribution when its session metadata is valid. It does not use the Windows host's cluster as a fallback. If an environment label is absent, continue in the normal WSL shell and check its own tools/configuration. For native interruption and resize behavior with +ssh inside WSL, use the Linux executable in that distribution when available; a Windows process bridge cannot recreate local Linux PTY behavior.

Remote safety#

  • Review host-key prompts before accepting them.
  • Keep credentials in established agents, keychains, and provider tools.
  • Avoid placing secrets in command text, aliases, logs, or copied examples.
  • Do not automatically retry destructive commands after a dropped connection.
  • Treat remote output and copied commands as untrusted input.

See Platform support and Workflow recipes for practical layouts.