Where the CLI prints the error
When a command fails, the CLI prints the error to stderr as plain text and exits with status1.
Although the following global flags modify the CLI’s output, they don’t silence error messages:
--log-formatand--log-destinationchange only the CLI’s log messages, so they don’t apply to error messages--silenthides update notices and profile notices, but not errors
Save the error
To keep the error, redirect stderr to a file with2>. For example, this command lists the folders at the root of a project’s prod environment. If the command fails, the error is saved to infisical.err:
- The CLI reads the machine identity’s access token from
INFISICAL_TOKEN, so the token doesn’t appear in the command 2>saves only stderr, so anything the command prints to stdout stays out of the file--silentkeeps update notices out of the file
What the saved error contains
If the machine identity in the example isn’t a member of the project, the command writes a file like this one:Request ID, the HTTP status code in Response Code, and the message from the server in Message. It doesn’t contain the access token, so you can safely store and share the error.
Look up the request ID
The request ID identifies the request in the Infisical server logs. Who can search those logs depends on where Infisical runs:- If you self-host Infisical, search your server’s logs for the request ID (it’s visible in every line for that request, and together those lines show the route, the response status, and the error)
- If you use Infisical Cloud, only Infisical can search the server logs, so include the request ID when you ask for help in the Infisical community