#1619·direnv

Escape codes for log coloring emitted only when there is no direnv.toml or TERM=dumb

Author: sooochCreated Sep 7, 2026Updated Sep 7, 2026
LabelsBug

Describe the bug In an interactive terminal, direnv log -status <MSG> is meant to prefix MSG with a reset escape code (^[[0m). direnv log -error <MSG> is meant to prefix the MSG with ^[[31m to turn text red and suffix it with ^[[0m.

Escape code are currently only emitted when the user does not have a direnv.toml or when there is a direnv.toml and TERM == dumb.

It looks like the main issue is that logError and logStatus (internal/cmd/log.go) both have the arms of their branch on c.LogColor reversed. This is likely because both used to branch on NoColor. Additionally, c.LogColor is only set to true if there is a direnv.toml and TERM != dumb (see internal/cmd/config.go).

To Reproduce

bash
export XDG_CONFIG_HOME=$(mktemp -d); mkdir -p "$XDG_CONFIG_HOME/direnv"
export TERM=xterm-256color
 
echo '--- no direnv.toml'
direnv log -status hello 2>&1 | cat -v # ^[[0mdirenv: hello
direnv log -error  oops  2>&1 | cat -v # ^[[31mdirenv: oops^[[0m
 
touch "$XDG_CONFIG_HOME/direnv/direnv.toml"      # empty file is sufficient
echo '--- direnv.toml exists'
direnv log -status hello 2>&1 | cat -v # direnv: hello
direnv log -error  oops  2>&1 | cat -v # direnv: oops
 
echo '--- direnv.toml exists, TERM=dumb'
TERM=dumb direnv log -status hello 2>&1 | cat -v # ^[[0mdirenv: hello
TERM=dumb direnv log -error  oops  2>&1 | cat -v # ^[[31mdirenv: oops^[[0m

Expected behavior When TERM == dumb, escape codes shouldn't be emitted. otherwise they should be emitted.

Optionally, restore the stderr-is-a-terminal check that the bash versions of log_{status, error} implemented via [[ -t 2 ]].

Environment

  • OS: NixOS 26.05
  • Shell: fish
  • Direnv version 2.37.1 (also repro'd on 2.36.0)

Additional context nix-community/nix-direnv colors its warnings by printing \e[33m before log_status and \e[m after. This only works when log_status doesn't emit the reset escape code prefix. Which implies to me that the author of _nix_direnv_warning probably had a direnv.toml. Once the above is fixed, nix-direnv's warning formatting will break for all users, not just those without a direnv.toml. It may be worth adding a direnv log -warning with a log_warning() wrapper so that downstream has a simple way of emitting colored warnings.