Why does my terminal title revert after I ssh into a remote host?

Your shell on the remote host is emitting its own OSC 0 / OSC 2 on every prompt — the bash PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"' pattern is the most common culprit, as is zsh's precmd hook. Either disable that hook on the remote, or set your local title *after* the ssh session ends (in a trap … EXIT or a shell wrapper function).

What's the difference between OSC 0, OSC 1, and OSC 2?

OSC 0 sets both the icon name and the window title. OSC 1 sets only the icon name (what shows on the dock / taskbar entry). OSC 2 sets only the window title (the OS-level window chrome). On macOS Terminal.app and most Linux terminals the icon name distinction is a no-op — OSC 0 and OSC 2 behave identically. iTerm2 and gnome-terminal honour the split when the icon-name slot is queried by the desktop.

OSC 0 / 2 — Set window/icon title

Change the terminal window's title bar text.

Byte forms

Every common string-literal form so you can paste-and-search either direction.

\\x1b[\x1b]0;TITLE\x07

\\033[\033]0;TITLE\007

\\e[\e]0;TITLE\a

ESC [ESC ] 0 ; TITLE BEL

hex1b 5d 30 3b ... 07

Description

OSC (Operating System Command) sequences start with ESC ] (\x1b]) and end with either BEL (\x07, the de-facto xterm terminator) or ST (\x1b\\, ESC \\, the standards-correct terminator from ECMA-48 §5.2.2). \x1b]0;TITLE\x07 sets both the window and icon titles; \x1b]1;TITLE\x07 sets only the icon title; \x1b]2;TITLE\x07 sets only the window title. The payload between the ; and the terminator is the new title text — UTF-8 is universally accepted on modern emulators. Used by every modern shell's PROMPT_COMMAND / precmd hook, by tmux's automatic-rename and set-window-option allow-rename, by terminal multiplexers' window-list display, and by tab-renaming tools.

Two portability traps recur on Stack Overflow. First, terminator choice: xterm and most modern emulators accept both BEL and ST, but the osc-terminator pitfall documents that some screen / tmux versions only forward titles when the terminator is ST (xterm-ctlseqs-strict), and Linux console / fbcon does not honor OSC titles at all (the support matrix above marks it no). Belt-and-braces code emits ST: \x1b]0;TITLE\x1b\\. Second, omitting the terminator entirely — common in code that gets cut off mid-string — leaves the OSC parser hanging until the next byte that happens to be a terminator (often the first BEL from the next prompt redraw, which makes the bug intermittent and hard to reproduce). Third, tmux: set -g allow-rename on must be set in .tmux.conf for OSC 0/2 from a pane to update tmux's window name; otherwise tmux strips the OSC and the host terminal never sees it. Apple Terminal.app honors titles but has its own AppleScript-level interface for tab titles that can override OSC on a per-window basis.

There is no "close" for a title — emitting a new OSC 0/2 replaces the previous one, and an empty payload \x1b]0;\x07 clears the title to the emulator's default (usually the running process name). The canonical shell-prompt pattern in bash is PS1='\[\e]0;\u@\h: \w\a\]\u@\h:\w\$ ' — the \[…\] brackets mark the escape as non-printing so PS1's column count stays correct, otherwise readline gets confused about line length and your wrap behaviour breaks. In zsh the equivalent is precmd() { print -Pn "\e]0;%n@%m: %~\a" }. The terminfo cap for setting the title is tsl (to_status_line) + fsl (from_status_line); few scripts bother since xterm-256color is now ubiquitous. Related: osc-hyperlink (OSC 8, inline clickable links), osc-cwd (OSC 7, working-directory advertisement that iTerm2 / Windows Terminal use to "new-tab in same dir"), osc-clipboard (OSC 52, set system clipboard).

Spec citation: xterm-ctlseqs (OSC 0/1/2)

Examples

bash

printf '\033]0;Hello window\007'

python

import sys; sys.stdout.write('\x1b]0;Hello window\x07')

fmt.Print("\x1b]0;Hello window\x07")

javascript

process.stdout.write('\x1b]0;Hello window\x07')

printf("\x1b]0;Hello window\x07");

Used in

Real-world tools that emit this sequence — anchors the bytes to commands you've already used.

bash, zshPROMPT_COMMAND / precmd hooks write `\x1b]0;…\x07` so each prompt updates the window title
tmuxset-titles option forwards window-name to the enclosing terminal
vim, neovim`set title` writes the buffer name (`filename - VIM`) as the window title
ssh clientmany distros patch ssh to set the title to `user@host` on connect
starship, oh-my-zsh window-title plugins

Frequently asked

Short answers to the questions developers actually search for this sequence.

Why does my terminal title revert after I ssh into a remote host?: Your shell on the remote host is emitting its own OSC 0 / OSC 2 on every prompt — the bash PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"' pattern is the most common culprit, as is zsh's precmd hook. Either disable that hook on the remote, or set your local title *after* the ssh session ends (in a trap … EXIT or a shell wrapper function).
What's the difference between OSC 0, OSC 1, and OSC 2?: OSC 0 sets both the icon name and the window title. OSC 1 sets only the icon name (what shows on the dock / taskbar entry). OSC 2 sets only the window title (the OS-level window chrome). On macOS Terminal.app and most Linux terminals the icon name distinction is a no-op — OSC 0 and OSC 2 behave identically. iTerm2 and gnome-terminal honour the split when the icon-name slot is queried by the desktop.

Common typos / look-alikes

Wrong forms developers commonly paste from Stack Overflow that look right but aren't — with the canonical correction inline.

\x1b]2;My Window Title\x1b]2;My Window Title\x07
OSC strings need an explicit terminator — either BEL (\x07) or ST (\x1b\\). Without it, every subsequent byte you write becomes part of the title string until the terminal hits a control byte that happens to terminate. The visible effect: your title is empty, and your prompt / next output mysteriously vanishes into the chrome.
\x1b]2 ;Title\x07\x1b]2;Title\x07
OSC parameters use ; (0x3B) directly after the numeric Ps with NO whitespace — spaces inside the OSC head break parsing in some terminals (notably older urxvt and the Linux console). The mistake is easy to make when copy-pasting from formatted documentation that visually pads the operator.
\x1b]0;Title\x1b\ (single backslash terminator)\x1b]0;Title\x1b\\ (ESC + literal backslash)
The ST terminator is the *two-byte* sequence ESC \ — that's 0x1B 0x5C. In a source-code string literal \x1b\\ is the right encoding (escape the backslash). Writing \x1b\ only emits one byte (ESC), leaving the title string unterminated. Common in language string-literal escaping where the trailing backslash got eaten by line continuation.

Terminal support

xterm: yes
Linux console (fbcon): no
macOS Terminal.app: yes
iTerm2: yes
Windows Terminal: yes
cmd.exe / ConPTY: yes
kitty: yes
alacritty: yes
WezTerm: yes
Ghostty: yes
GNOME Terminal: yes
Konsole: yes
tmux: yes
GNU screen: yes

xterm	Linux console (fbcon)	macOS Terminal.app	iTerm2	Windows Terminal	cmd.exe / ConPTY	kitty	alacritty	WezTerm	Ghostty	GNOME Terminal	Konsole	tmux	GNU screen
yes	no	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes	yes

Related sequences

In the family cookbook

OSC cookbook · 1. The envelope — `\x1b]` … `\x07` or `\x1b\\`