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!

[ad8-bdl]

I'm unclear as to the reason why this has been moved to discussion. This is a bug; by all means close it with wontfix if it's not worth fixing (I get it, likely an uncommon use case), but sidelining it over to discussions is misleading and hides the issue should someone else come across it, or if someone is evaluating the tool.

[duedares-rvj]

@ad8-bdl Thanks for following up and I really appreciate the feedback here.

Just to clarify, we don’t consider this a bug. The CLI was not designed with TERM=dumb in mind, so it’s not expected to handle that setting gracefully. At most, this would qualify as a feature request or an enhancement. And we definitely weren’t trying to sideline the issue. It was moved to Discussions because that’s where we collect community feedback and interest around lower-priority or edge-case improvements.

Our roadmap is shaped heavily by usage patterns and customer demand. At this point, this specific enhancement hasn’t surfaced as a common need, but we parked it in Discussions precisely so we can revisit if there's broader interest.

For reference, other mature CLI projects treat similar issues in the same way:
cli/cli#5407
jira-cli#291

Thanks again for engaging on this.
Regards.