Allow ANSI color codes

[konstin]

Feature Request

#3368 starts escaping ANSI control sequences to avoid actions such as setting the titlebar and screen clearing. To do so, it escapes all ANSI control sequences.

The change in #3368 has led to users confused about why there are escape sequences in their output (astral-sh/uv#15840).

Would it be possible to only escape (or better, strip) non-color control sequences? Color codes are purely decorative, unlike other control characters. This would allow us to continue logging color-adorned messages in CLI logs.

This feature request has the same motivation but a different specific request than #3369.

Crates

tracing-subscriber

Alternatives

If it it not possible to filter for specific ANSI escapes, would it be possible to strip ANSI escapes instead of escaping them, and to add an option to allow us to perform our own filtering? We're already using anstream as output stream to strip ANSI sequences for non-color targets, we can extend this to perform the filtering for dangerous codes ourselves.

[ShayBox]

I've also run into this in my program, all colored output are now showing as escape sequences in 0.3.20, I've had to lock to 0.3.19 for this breaking behavior. (Should this have been 0.4?)

I wasn't aware you could set the titlebar with escape sequences, I've been using crossterm for that. (Maybe a way to disable this or allow trusted escape sequences?)

[KennanHunter]

Also had all of my colorization print as escape codes instead of properly colorizing.

There already exists .with_ansi() on the tracing subscriber builder, why would setting that to true still filter ANSI escape codes? If you're filtering no matter what .with_ansi(bool) is set to, it seems like the documentation should be updated on that.

[james7132]

Echoing this as well, we're seeing reports like bevyengine/bevy#21164 that are making similar complaints.

[nagisa]

To me an interesting oversight in the current fix seems to be that strings formatted as key-values are still passing through the escape codes. It seems to be just about as iffy as the escapes in the messages, if not more so.

Either way the proper work-around while waiting for some sort of configuration option is to implement your own event formatter/visitor.

[ShayBox]

The best workaround right now is to use version 0.1.19 instead of 0.1.20. This is a regression and should be YANKED, because 0.1.20 was not intended to be a breaking release — yet it introduced a change that broke functionality.

While it may sound harsh, this is indeed a breaking change shipped under a supposedly non-breaking version update. It should either be yanked and re-released as 0.2.0, or fixed and published as 0.1.21.

We've tracked the problem down to the tracing crate, but not every developer will go through the trouble of rolling back their Cargo.lock (if they even have one) or manually downgrading dependencies until they find the culprit. Because this was released as a non-major update, it affects every project that depends on tracing, even indirectly.

Even if a future update restores ANSI color code support, the option to sanitize ALL escaped sequences must be disabled by default to preserve compatibility with existing behavior. Enabling it by default in a 0.1.x release is exactly the type of breaking change that SemVer forbids — it should only be enabled by default in a 0.2.x release.