Read-Only Mode

Read-only mode freezes a single terminal surface so it doesn't accept input. The shell or program keeps running and producing output, but nothing you type or click is sent to it. This is useful for:

• Watching a long-running process without risk of accidentally typing into it (a kubectl logs -f, a build, a server you don't want to Ctrl+C).
• Sharing a screen recording or live demo where viewers shouldn't see you accidentally interrupt the program.
• Pinning a "reference" terminal while you work in another split.

Use the toggle_readonly action. There is no default keybinding, so bind it yourself:

keybind = ctrl+shift+r=toggle_readonly

The first invocation enables read-only; the second invocation restores normal input. The toggle applies only to the currently focused surface, not the whole window or tab. Other surfaces continue to accept input.

On Windows there is no visual indicator for read-only mode. The tab strip and the surface itself look exactly the same as always, so pick a keybinding you'll remember. (The GTK UI on Linux does draw a banner across the top of the surface; nothing equivalent exists on Windows yet.)

While the surface is read-only:

• Keyboard input is not sent to the PTY (no key encoding, no shortcuts that target the running program).
• Mouse events (clicks, motion, scroll wheel reporting) are not sent to the PTY.
• Pasting text into the surface does nothing.

This means a process you've started cannot see anything you do. It will continue producing output as if you'd stepped away from the keyboard.

Read-only only blocks input to the PTY. The terminal UI itself remains fully functional:

• You can still select text with the mouse or keyboard.
• You can still copy selections to the clipboard.
• You can still scroll the viewport (mouse wheel, scroll keys, search).
• Keybindings that target Wintty itself (open settings, new tab, copy, toggle command palette) still work. Paste is the exception: it is blocked along with the rest of the input path, as noted above.
• The terminal continues to render new output.

This is the point of the feature: you can observe and interact with the terminal as a viewer, just not as the running process's input.

In the terminal core, a read-only surface always asks for confirmation before closing, even if no process is currently running, and regardless of your confirm-close-surface setting. This is intentional: the most common reason to read-only a surface is to watch a specific output, so accidentally closing it would be especially annoying.

Note

The Windows app does not implement this yet. It never asks the core whether a surface needs a close confirmation, and it does not read confirm-close-surface either. The only close prompt on Windows is the one for closing a tab that holds more than one split, which is a plain pane count check and ignores read-only entirely. So a read-only surface on Windows closes without any extra prompt.

Action	Purpose
toggle_readonly	Toggle read-only mode on the focused surface