Terminal markup bugs: doesn't respect TERM

[ad8-bdl]

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of this project and the issue still persists.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

auth0 appears to ignore TERM capabilites and continues to emit escape sequences even when TERM=dumb

Expectation

auth0 should not use terminal escape markup when the terminal does not support it.

This bug makes it impossible to work around a separate bug re. inappropriate markup (to be filed momentarily).

Reproduction

% SHELL=/bin/bash TERM=dumb script         
Script started, output file is typescript
bash-3.2$ id='auth0|xxx'
bash-3.2$ auth0 users show "${id}"

=== xxx.au.auth0.com user

  ID          auth0|xxx      
  EMAIL       a@b.com  
  CONNECTION  Connection                      
bash-3.2$ exit

Script done, output file is typescript

• if you're running the above in an xterm/like, you'll observe the output is marked up despite TERM=dumb; if you're actually running the above in a terminal that doesn't support escape sequcnes you'll see a mess of escape codes

Examine the typescript file: (I've replaced the non-printable ESC with \e)

Script started on Mon Jul  7 10:17:23 2025
bash-3.2$ id='auth0|xxx'
bash-3.2$ auth0 users show "${id}"
\e[?25l
\e[K
⣾
\e[K
⣽
\e[K
⣻\e[?25h
\e[K
\e[2m===\e[0m \e[1mxxx.au.auth0.com\e[0m user

  ID          \e[2m\e[2mauth0|xxx\e[0m\e[0m      
  EMAIL       a@b.com  
  CONNECTION  Connection                      
bash-3.2$ exit

Script done on Mon Jul  7 10:17:41 2025

Auth0 CLI version

auth0 version 1.15.0 489abd0

[ramya18101]

Thank you for raising this valid request. We recognize that some users still rely on terminals that don’t support escape sequences, and respecting the TERM setting makes sense.

At the moment, this specific improvement isn't on our immediate roadmap, but we’re moving your issue to discussions to gather more feedback from the community about this requirement. If we see more interest or traction from other users, we’ll definitely revisit this and try to include it in our future planning.

Thanks again for your feedback!