Scrolling and scrollback

Scrolling on a phone terminal looks like one gesture but is actually three different things: scrolling the on-screen view, scrolling the in-app scrollback buffer, and reaching history that lives further back on the host. The right answer depends on which one you mean.

Scroll the visible view

Drag up on the terminal surface to scroll back. Drag down to return. A scroll past the bottom dismisses the keyboard by default — this is configurable in Gestures.

The terminal stays attached while you scroll. New output keeps arriving at the bottom; you stay where you are.

In-app scrollback

Moshi keeps a scrollback buffer in the app with a configurable line limit. The default is intended for agent output and build logs without making the terminal unbounded. Raise the limit in Settings -> Terminal if your agents emit very long output and you want more in-app history.

This buffer holds only what Moshi has rendered since the session started or reconnected. It is not a recording of everything the host ever printed.

Why mosh seems to "lose" scrollback

The mosh protocol does not transmit scrollback. When mosh reconnects after a network change or app resume, only the current visible screen is restored — anything that scrolled off before reconnect is gone from the wire. SSH has the same limit when a session is interrupted.

If you need history that survives reconnects, scrollback has to live on the host, not in the wire protocol.

tmux is the durable answer

Run your shell inside tmux on the host. tmux holds its own scrollback buffer per pane, on the host, independent of the connection.

$tmux new -s moshi

When Moshi reconnects to that tmux session, the full host-side scrollback is still there. See tmux for the durable workspace pattern.

Scroll speed (it's a tmux setting)

If you're running tmux on the host, Moshi's drag gesture isn't moving the terminal directly — it's translated into mouse-wheel events and forwarded to tmux. tmux then decides how many lines each wheel event scrolls. So when scrolling feels too slow or too jumpy, the knob you want is on the host, not in the app.

Each wheel "tick" defaults to 5 lines on macOS tmux builds, which on a phone-sized terminal often feels jumpy. Rebind WheelUpPane and WheelDownPane in ~/.tmux.conf and lower the -N count for finer control:

set -g mouse on
bind -T root WheelUpPane   send-keys -X -N 3 scroll-up
bind -T root WheelDownPane send-keys -X -N 3 scroll-down
bind -T copy-mode-vi WheelUpPane   send-keys -X -N 3 scroll-up
bind -T copy-mode-vi WheelDownPane send-keys -X -N 3 scroll-down

The -N 3 is the lines-per-event count: lower it (try 2) for finer scrolling, raise it for faster jumps. Reload without restarting tmux:

$tmux source-file ~/.tmux.conf

Outside tmux (a plain SSH or mosh shell), there is no per-event line setting on the host — the in-app scrollback uses Moshi's own scroll handling, and the gesture itself controls speed.

tmux copy mode for searching

Moshi's drag-to-scroll covers the in-app buffer. To scroll, search, and copy through tmux's full host-side history, use tmux copy mode:

Copy mode is the right tool for "find that error message from twenty minutes ago" — it scrolls the host buffer, not just the visible Moshi view.

When you really need a transcript

For permanent searchable history, neither buffer is the answer. Use one of:

• tmux capture-pane -p -S - to dump the current pane's history to a file.
• Shell-level redirection (tee, script).
• The agent's own transcript files (Claude Code, Codex, and OpenCode all keep session logs on the host).

These survive reboots; scrollback buffers do not.