A scriptable status bar has been added with 11 built-in configurable components.
A new "Minimal" theme has been added to reduce visual clutter.
A new window type of "Compact" combines the tab bar and title bar.
Session, tab, and window titles have been revamped to be more flexible and comprehensible. You can now configure them separately and select what information is shown per profile. They are integrated with the new Python scripting API.
Tabs may now have icons: either an icon indicating the running app, or a fixed icon per profile.
The display of Sixel images is now supported.
Add menu item to arrange split panes evenly. In tmux, this uses the tiled layout.
Greatly improved support for background images: they may now span split panes and you can adjust how they are scaled to avoid stretching.
Add support for reporting keystrokes with CSI u.
New type of trigger added that turns text into a hyperlink.
New type of trigger added that adds annotations to the matching text.
You can now export a recording of your screen from the Instant Replay panel.
A new toolbelt tool, Actions, provides shortcuts to frequent actions like sending a snippet of text.
Numerous visual improvements.
Update app icon.
You can now change the color preset from the Open Quickly window.
Added an advanced pref for the height of the underline cursor.
The state of various terminal emulation flags is now exposed in Session > Terminal State.
Remove the bell icon from tabs more aggressively.
Various pages of preferences have been rearranged to make more sense or be more visually pleasing.
A new menu item lets you configure cmd-+ and cmd-- to adjust the underlying profile rather than only the current session.
By default the tab bar now stretches to fill the available width so it looks more like a native tab bar. You can change this in Prefs > Appearance.
Add a new proprietary control sequence to bounce the app icon only one time.
Add support for setting the proxy icon by control sequence.
Add support for broadcasting passwords to multiple sessions from the password manager. Off by default.
Update "Terminal.app Compatibility" key mapping for option left and right arrows.
Add support for natively drawn Powerline glyphs, allowing you to use any font and still get the fancy arrows. They also align properly with other elements, which the Powerline fonts do not always do.
Cmd-clicking on filename[line,column] will now open the file to the specified line and column.
Add "use transparency" as a profile setting for newly created windows.
Adjust how underlines are drawn to have a more correct baseline offset.
Add an advanced pref to swap find next/find previous behavior (since the default does not conform to macOS norms)
Buttons in modal alerts now all have keyboard shortcuts.
The default scheme for URLs when you cmd-click is now https rather than http. You can change it with an advanced pref.
Sparkle updates now use EdDSA signatures. DSA signatures will be gradually phased out.
Add an advanced preference to show a hint with split pane direction in menu items.
Add an option to preserve window size when tab bar shows or hides
You can now use the password manager when entering a password for secure copy.
Adds support for the DECRQM control sequence.
Security-Related Changes in iTerm2 Version 3.3
Version 3.3 of iTerm2 will add support for a Python API that enables
applications to control iTerm2 and access its data for the purposes of
automation and customization.
This document lays out the security model so that users can judge if this is a
feature they feel comfortable using.
By default, the Python API is disabled. The only way it can be enabled is
through the user consenting by an alert, or by a change to NSUserDefaults.
When the Python API is enabled, iTerm2 listens on TCP port 1912 in address 127.0.0.1.
As a result, only connections from localhost are accepted. This is the most important security feature: only applications running on the same machine
The websocket protocol is used.
Google Protocol Buffers are exchanged over the websocket. They contain
request-response pairs originated by the client, or notifications originated by
iTerm2. The proto file is here:
Once connected, the user must grant the application permission. A grant may be one-time or persistent. Persistent grants expire after thirty days. Denials may be one-time or permanent. Users can view and modify grants in preferences.
iTerm2 acts on all requests from an authenticated connection.
We cannot completely defend against unsandboxed programs that can run arbitrary commands on the user's machine with the user's privileges. They already effectively have access to everything, since they could use ptrace to examine and change memory belonging to iTerm2, or just grant themselves permission by modifying user defaults.
Explicit user permission is necessary to enable the API. The user will be prompted when it's needed, such as when a script is launched.
When a program connects to the API for the first time, the user will be asked to give it permission.
When a program creates a websocket connection to iTerm2 it must include the
following HTTP header:
This further enforces the requirement that connections originate locally.
Some API-using programs are invoked by iTerm2. For example:
The user can choose a script from the Scripts menu.
On launch, scripts in ~/Library/Application Support/iTerm2/Scripts/AutoLaunch are run automatically.
These programs are run with an environment variable ITERM2_COOKIE that
contains 16 bytes from /dev/random. When connecting, a program may present
its cookie in the x-iterm2-cookie header. If an incoming connection presents
a valid cookie, it is authenticated and the cookie is removed from the pool of
Otherwise, all processes on the system are searched to discover which owns a
TCP socket with a connection to localhost with the correct pair of local and
remote port. This works similarly to lsof.
Once the process ID is determined, its command line is fetched with the
At this point, there are four possibilities:
Option 1: The connecting process is a Cocoa app. In this case, the name of the
application used as the prompt to the user.
Option 2: The connecting process looks like Python. The command line is parsed
and the name of the script is extracted and used as the prompt to the user.
Option 3: The connecting process exists but is neither of the above. The
executable is used as the prompt to the user.
Option 4: The process's identity could not be discovered. The connection is
The user prompt is shown, with the option to reveal the full command line.
The user may choose to temporarily or permanently allow access from this program. If they choose to give access permanently, an access key is recorded. Its value depends on which of the first three
cases is in effect:
Option 1: The bundle ID (or full command line if it could not be found)
combined with the filesystem device ID of the executable, its inode, and the
SHA-256 of the executable.
Option 2: The relevant parts of the Python command line: the module if given
with -m, the command if given with -c, and the script. Additionally, the
filesystem device ID of the python executable and its node and SHA-256 hash are
Option 3: The path to the executable, plus its filesystem device ID, inode, and
Once a program has been granted permanent access any connection with a matching
authentication key will be allowed.
Users have the option of sharing scripts. An Export option allows a script to
be bundled into an archive, including metadata such as its pip dependencies and
minimum python version, as well as all code belonging to the script.
An exported script may be signed with a code signing certificate. Signed
scripts enjoy two benefits:
They may be installed directly into the AutoLaunch folder after getting
confirmation from the user.
They may be opened by double-clicking the file or dragging it to the iTerm2
Unsigned exports are simply zip files that the user may install by extracting
them to the right location or by using the Scripts > Manage > Import menu.
Even signed scripts require user consent to be installed. Users have the option
of unarchiving the script and inspecting its contents instead of installing it.
Signed scripts are stored in .its files. This is a container which consists
of a sequence of (tag,length,value) triples. The tag indicates the role of the
value. The length gives its size in bytes. The value is the payload. The
following tags are defined:
Header: Identifies the file type.
Payload: The contents of a zip file.
Metadata: Gives the version of the container format.
Signature: Gives the signature of the zip file.
Certificate: Gives a certificate that may be used to validate the
signature. There may be more than one certificate (which is useful when an
intermediate signing cert is needed).
The signing algorithm signs the SHA-256 digest of the zip file using whatever
algorithm is appropriate for the type of key the user selects when picking
their signing identity.
Because Apple's Security library is used to perform signature verification,
bundled certificates may or may not be used. Root certificates are ignored.
Certificate revocation is supported via macOS's standard mechanisms, whatever
they may be for the user's version of macOS.
The Python Runtime, which includes a Python executable and its associated files
(such as the standard library) is provided as an optional component the user
may download after installing iTerm2. They are prompted to install it the first
time they try to use the Python API.
The runtime comes as a zip file. Its URL is discovered from a JSON files that
contains its version and a signature of the SHA-256 digest of the zip file
using a 4096-bit RSA key. Apple's Security library is used to perform signature
verification. The public key is hard-coded into iTerm2.
A newer version of Sparkle is now used. It uses EdDSA signatures for verifying updates, versus DSA in the older versions. The public key is hard-coded into iTerm2. There will be a transition period during which both DSA and EdDSA will be used. Eventually DSA support will be dropped. This is necessary because older clients in the field will need to upgrade to a transitional release with both signatures. Transitional releases will be able to upgrade to a future release with only EdDSA. Sparkle does not support upgrading from a package signed with only DSA to a package signed with only EdDSA (https://github.com/sparkle-project/Sparkle/issues/1355).
The application is also code signed using Apple's standard mechanism for macOS applications.