auth0 users show --json emits non-JSON text (tenancy info)

[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 users show "$id" --json emits non-JSON text

Expectation

Output in JSON format should be in JSON format.

Specifically, it's spitting out the tenancy information. There should at least be a flag to suppress that.

This seems to be endemic to most (all?) commands that are tenancy-specific.

EDIT: I see this output is actually to stderr; so a simple workaround is to redirect that.

Reproduction

% auth0 users show 'auth0|xxx' --json

=== xxx.au.auth0.com user

{
    "user_id": "auth0|xxx",
    "connection": "xxx",
...
}

Auth0 CLI version

auth0 version 1.15.0 489abd0

[ramya18101]

Hello @ad8-bdl ,

Yes, We noticed about the tenancy information which leads to stderr, I'm creating a task internally and shall pick this up shortly.

[michaelbiriley-auror]

An approach could be to have some cli flags which can omit all the content that is sent to stderr. As it stands, many work-arounds are required to avoid causing errors in CICD when the auth0 cli tooling continually writes messages into stderr.

[ad8-bdl]

stderr should indeed be reserved for errors; not used as regular output. Full stop - standard behaviour should not be conditional on any flag or option.

[ramya18101]

Hello @ad8-bdl, @michaelbiriley-auror

Thank you for your thoughtful feedback. We completely agree with the points you raised. but changing the existing behavior would affect current users.

With the new --json-compact flag, all header messages are fully suppressed, preserving clean, parsable output for automation use.

[ramya18101]

All said, we’ll definitely give this more thought for a future major release and see if we can make the experience more robust. Instead of closing this issue, we are going to park this in under Discussions and hear more from the community.