Skip to content

Terminal markup bugs: doesn't respect TERM #1266

Closed

Description

@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

Activity

  1. added
    bugThis points to a verified bug in the code
    on Jul 7, 2025
  2. ramya18101 commented on Jul 30, 2025

    @ramya18101
    Contributor

    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!

  3. locked and limited conversation to collaborators on Jul 30, 2025
  4. converted this issue into a discussion #1290 on Jul 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugThis points to a verified bug in the code

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions