NeoShell Note
zellij and tmux for Persistent Mobile SSH
How do zellij and tmux keep a mobile SSH workspace alive after the connection drops?
tmux and zellij remain the default answer for keeping host-side shell state alive when mobile SSH reconnects are routine.
Short answer
If you want to keep a mobile SSH workflow alive across disconnects today, zellij and tmux are still the fastest and safest host-side fix.
They keep the workspace alive on the host, so reconnecting the client does not destroy the work itself.
Why this problem happens
A shell session that lives directly on the SSH connection dies too easily on mobile. The process tree, scrollback, and active commands should not be tied to one fragile client transport.
Multiplexers solve that by making the host own the workspace instead of the transient client session.
tmux and zellij on iPad with NeoShell
In NeoShell, multiplexer behavior belongs to the Project rather than the Host Profile. Open Project Settings, find Session Persistence, and choose tmux, zellij, or None.
For tmux, NeoShell checks for the named session and runs an attach-or-create command. For zellij, it attaches to the named session when available and creates it in the project directory otherwise. Reconnecting to the Project repeats that attach path instead of opening an unrelated fresh shell.
- Choose tmux when the remote workflow already uses tmux sessions and familiar tmux commands.
- Choose zellij when the host workspace is organized around zellij sessions and panes.
- Choose None for a direct shell when persistence is unnecessary or the host has no multiplexer installed.
- Session names are sanitized before NeoShell uses them in remote commands.
Recommended setup
Attach to one named workspace and keep reconnecting into that workspace instead of starting a fresh shell every time.
If you later need stronger mobile continuity, compare this with resumable transport rather than replacing the multiplexer blindly.
tmux new -As workzellij attach -c workTradeoffs and limits
You still need to learn the multiplexer layer and manage it intentionally. That extra layer is worth it because it separates workspace life cycle from network life cycle.
If your main pain is the transport itself rather than the host workspace, neosh may be the better next step.
FAQ
What do tmux and zellij preserve?
They preserve host-side workspace state such as panes, processes, and shell sessions even after the client disconnects.
Does this replace transport-level resume?
No. Multiplexers solve the problem at the workspace layer, while resumable transport addresses the session-connection layer.
Is this still useful if I also use neosh?
Yes. Many users still want tmux or zellij for pane management and workspace organization even when transport resume exists.
Can NeoShell automatically attach to tmux or zellij?
Yes. Set Session Persistence in Project Settings to tmux or zellij. NeoShell resolves the remote binary, attaches to the named session when it exists, or creates it in the project directory when needed.
What happens if tmux or zellij is not installed?
NeoShell reports that the selected multiplexer is unavailable and prompts you to install it on the host or switch the Project session mode to zellij, tmux, or None.