iTerm now supports OSC 9;4 (terminal window progress bar) #16506

case · 2026-01-14T18:25:31Z

What does this PR try to resolve?

Per the iTerm version 3.6.6 release - "Add support for OSC 9;4 progress bars"

I added iTerm to nextest here and they suggested I add it to Cargo as well.

How to test and review this PR?

I've test this locally, but it isn't really a unit test or integration test candidate.

Here's the output from my local iTerm console:

$ echo $TERM_PROGRAM
iTerm.app

rustbot · 2026-01-14T18:25:36Z

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

epage · 2026-01-14T18:30:08Z

src/cargo/core/shell.rs

+    let iterm = std::env::var("TERM_PROGRAM").ok() == Some("iTerm.app".into());

-    (windows_terminal || conemu || wezterm || ghostty) && stream.is_terminal()
+    (windows_terminal || conemu || wezterm || ghostty || iterm) && stream.is_terminal()


Do old versions gracefully ignore these escape codes?

Good question! I'll follow up with @gnachman about this.

Likely you can just do a quick check by forcing this on in older versions. The main reason this comes up is

For some escape code sequences, there are bugs in older versions

I think it was this escape sequence that partially overlapped with another one and terminals would do weird things if they didn't guard against that

Older versions will treat them as a request to post a notification. Would it be useful to have a way to detect support for OSC 9 as statusbar?

Depending on how its done, that could spam users. It would be good if we could do version detection to avoid those old versions.

I've updated iTerm2's feature reporting to support parameter packs. The documentation on the feature reporting mechanism is here:

https://iterm2.com/feature-reporting/

The website doesn't have the progress bar feature yet, but you can see the change to the docs here:

gnachman/iterm2-website@41b36d6

Here is a sample program for parsing and detecting the PROGRESS feature:

https://gist.github.com/gnachman/1aee2d5f440bc5b82e1db405ef67195f

Oh, and my update will be in the next nightly build if you want to verify. It should be released in about 5 hours at https://iterm2.com/nightly/latest

Thanks @gnachman!

@epage I've updated this PR with @gnachman's sample program, and a simple test.

epage · 2026-01-14T18:32:07Z

Regarding CI, it was fixed in crate-ci/typos#1447, so we just need to update. I'll post a PR.

This will unblock rust-lang#16506

### What does this PR try to resolve? This will unblock #16506 ### How to test and review this PR?

epage · 2026-01-14T20:01:20Z

A rebase should resolve the CI failure.

weihanglo · 2026-01-17T20:33:34Z

FWIW, it would be nice if we could avoid merge commits in pull requests. Feel free to rebase as needed. Keeping the history linear makes PRs easier to read and review, and ideally we’d only see a merge commit when the PR itself is merged, not merges from master along the way.

case · 2026-01-17T20:40:15Z

FWIW, it would be nice if we could avoid merge commits in pull requests. Feel free to rebase as needed. Keeping the history linear makes PRs easier to read and review, and ideally we’d only see a merge commit when the PR itself is merged, not merges from master along the way.

Oops, my apologies 🙏

weihanglo · 2026-01-22T00:57:15Z

src/cargo/core/shell.rs

+    #[test]
+    fn term_features_progress_detection() {
+        // With PROGRESS feature ("P")
+        unsafe { std::env::set_var("TERM_FEATURES", "MBT2ScP") };


Note that the default test harness (libtest) runs test in multi-threads. You might not want teset to affect each other. (though I know it is rare and doesn't matter right now).

What about we do this

fn term_features_has_progress(value: &str) -> bool

So that you can

let iterm = std::env::var(…).ok().map(term_features_has_progress).unwrap_or(false);

weihanglo · 2026-01-22T01:00:43Z

src/cargo/core/shell.rs

    let ghostty = std::env::var("TERM_PROGRAM").ok() == Some("ghostty".into());
+    // iTerm added OSC 9;4 support in v3.6.6, which we can check for.
+    // See https://github.com/rust-lang/cargo/pull/16506#discussion_r2706584034 for reference.
+    let iterm = term_features_has_progress();


Should we check TERM_PROGRAM == "iTerm.app" first? While TERM_FEATURES looks like an iTerm stuff, it is too general that I am afraid some other emulator might have the same env with different intepretation.

Yep this is a great callout, I'll add this momentarily.

I'd ask that you not add the TERM_PROGRAM check. It is part of an effort of the now-defunct terminals working group to develop a flexible capabilities reporting mechanism, which has been a sore spot for decades. At the moment only iTerm2 supports this so you're completely safe. It is very helpful to have popular apps use TERM_FEATURES to avoid fragmentation in the future. The trouble with using TERM_PROGRAM and related signals is that new terminals are forced to emulate existing ones for things to work right, and we ended up with a User-Agent-style mess many times over. This is our best chance to break out of that trap. Thank you for listening to my rant :)

I view this as an allowlist and we can add more. Individual users can overwrite the allowlist using their config. I don't think terminals should lie about who they are.

An allowlist effectively makes TERM_FEATURES iTerm-specific forever: other terminals won’t adopt a signal that major apps ignore by default, and users won’t extend an allowlist. This is a rare chance for terminals and applications to converge on a real capability-reporting mechanism instead of identity checks. Treating TERM_FEATURES as a pure capability signal helps avoid further fragmentation and reduces the long-term need for terminal-specific special cases.

I'm grateful for your help and I'll back off now. I'm glad OSC 9;4 is getting more use, anyway, and it'll be a nice addition to cargo.

weihanglo · 2026-01-22T13:50:32Z

@case you might need to rebase onto the master branch again due to #16539

case · 2026-01-22T16:36:59Z

@case you might need to rebase onto the master branch again due to #16539

Sure thing! This is done.

weihanglo · 2026-01-22T16:56:33Z

Rust 1.93 just got released today, and we need to update things accordingly (see #16543), so yeah you need to rebase again. Sorry about the inconvenience.

(The docs is required to pass, the check-version-bump isn't)

- Check for TERM_PROGRAM=iTerm.app before checking TERM_FEATURES - Safer env var testing per multi-threaded testing

rustbot · 2026-01-22T17:11:11Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

case · 2026-01-22T17:13:23Z

Rust 1.93 just got released today, and we need to update things accordingly (see #16543), so yeah you need to rebase again. Sorry about the inconvenience.

(The docs is required to pass, the check-version-bump isn't)

All good, I just rebased again.

weihanglo

Thanks for working with us!

View changes since this review

Update cargo submodule 14 commits in 85eff7c80277b57f78b11e28d14154ab12fcf643..efcd9f58636c1990393d495159045d9c35e43b8f 2026-01-15 16:18:08 +0000 to 2026-01-23 13:50:59 +0000 - chore(deps): update cargo-semver-checks to v0.46.0 (rust-lang/cargo#16548) - Increase cache_lock test timeout (rust-lang/cargo#16545) - iTerm now supports OSC 9;4 (terminal window progress bar) (rust-lang/cargo#16506) - chore: Updated compiler errors for Rust 1.93 (rust-lang/cargo#16543) - test(build-std): adjust snapshot (rust-lang/cargo#16539) - chore: bump to 0.96.0 (rust-lang/cargo#16538) - fix: update `resolve_all_features()` to filter pkg deps (rust-lang/cargo#16221) - fix: show implicit_minimum_version_req emitted source once per package (rust-lang/cargo#16535) - fix: `--remap-path-scope` stabilized in 1.95-nightly (rust-lang/cargo#16536) - feat(lints): Add non_kebab_case_bin lint (rust-lang/cargo#16524) - fix(rm): Suggest table flags when none are specified (rust-lang/cargo#16533) - fix(patch): clean up patch-related error messages (rust-lang/cargo#16498) - Store artifact deps in build unit dir (rust-lang/cargo#16519) - refactor(timings): reuse timing metric collection logic between `--timings` and `-Zbuild-analysis` (rust-lang/cargo#16497)

rustbot assigned weihanglo Jan 14, 2026

rustbot added A-console-output Area: Terminal output, colors, progress bar, etc. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 14, 2026

epage reviewed Jan 14, 2026

View reviewed changes

epage added a commit to epage/cargo that referenced this pull request Jan 14, 2026

chore: Update typos

41f2803

This will unblock rust-lang#16506

epage mentioned this pull request Jan 14, 2026

chore: Update typos #16507

Merged

github-merge-queue bot pushed a commit that referenced this pull request Jan 14, 2026

chore: Update typos (#16507)

b492376

### What does this PR try to resolve? This will unblock #16506 ### How to test and review this PR?

This comment has been minimized.

Sign in to view

weihanglo reviewed Jan 22, 2026

View reviewed changes

case force-pushed the iterm-osc94 branch from d675c24 to 9ab6b3c Compare January 22, 2026 01:48

This comment has been minimized.

Sign in to view

case force-pushed the iterm-osc94 branch from 9ab6b3c to 9a6d566 Compare January 22, 2026 16:34

This comment has been minimized.

Sign in to view

case and others added 3 commits January 22, 2026 09:11

iTerm now supports OSC9;4

2793c92

Support iTerm's TERM_FEATURES

85c7485

Address PR feedback

ab7d3dd

- Check for TERM_PROGRAM=iTerm.app before checking TERM_FEATURES - Safer env var testing per multi-threaded testing

case force-pushed the iterm-osc94 branch from 9a6d566 to ab7d3dd Compare January 22, 2026 17:11

weihanglo approved these changes Jan 22, 2026

View reviewed changes

weihanglo added this pull request to the merge queue Jan 22, 2026

Merged via the queue into rust-lang:master with commit 29b2a54 Jan 22, 2026
28 of 29 checks passed

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 22, 2026

case deleted the iterm-osc94 branch January 22, 2026 19:13

weihanglo mentioned this pull request Jan 23, 2026

Update cargo submodule rust-lang/rust#151544

Merged

case mentioned this pull request Jan 24, 2026

terminalprogress causes thousands of iTerm2 alerts pytest-dev/pytest#13896

Closed

rustbot added this to the 1.95.0 milestone Jan 24, 2026

iTerm now supports OSC 9;4 (terminal window progress bar) #16506

iTerm now supports OSC 9;4 (terminal window progress bar) #16506

Uh oh!

Conversation

case commented Jan 14, 2026

What does this PR try to resolve?

How to test and review this PR?

Uh oh!

rustbot commented Jan 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage commented Jan 14, 2026

Uh oh!

epage commented Jan 14, 2026

Uh oh!

This comment has been minimized.

weihanglo commented Jan 17, 2026

Uh oh!

case commented Jan 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

weihanglo commented Jan 22, 2026

Uh oh!

This comment has been minimized.

case commented Jan 22, 2026

Uh oh!

weihanglo commented Jan 22, 2026

Uh oh!

rustbot commented Jan 22, 2026

Uh oh!

case commented Jan 22, 2026

Uh oh!

weihanglo left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

weihanglo left a comment •

edited by rustbot

Loading