[aroff]

What

init_default_logging() built its fmt layer with the default ansi = true, so every line carried ANSI escape codes even when stdout is a pipe or a container log. In Kubernetes those codes land verbatim in kubectl logs and in Loki.

The default subscriber now calls with_ansi(cli_mode::should_color_output()), the crate's existing stdout colour rule: NO_COLOR > FORCE_COLOR > terminal. Both bodies of install_default_logging (with and without telemetry) use it.

Found while wiring logging into Pauta's serve (rudaia-hq/pauta spec 011), whose pod logs go to Loki.

Tests

tests/unit/default_logging_color.rs (unit_default_logging_color, feature observability). Installing the subscriber is a one-way, process-global step, so each case re-runs the test binary with stdout piped:

• a_pipe_gets_plain_lines: no \x1b in the output. Fails on main (checked by reverting the fix).
• force_color_colours_a_pipe: FORCE_COLOR=1 gives escape codes, so the check above means something.
• no_color_wins_over_force_color.

Runs under --features observability and --features telemetry. The existing unit_telemetry_logging_guard, unit_telemetry_slot_forwarding and unit_telemetry_startup_logging_upgrade still pass. cargo fmt --check and cargo clippy --all-features -- -D warnings are clean.

What could leak

Nothing new. This changes only the formatting of lines that were already written.

🤖 Generated with Claude Code