Explain --debug-file in messaging warning

Debug techniques

Press Ctrl+O to open the transcript view to check the outcome of a hook run:

• Successful run: you see nothing, unless the hook's JSON surfaces something, such as systemMessage or Stop hook feedback.
  • To confirm a hook ran, check for its effect, like a reformatted file, or turn on debug logging as described below and trigger the hook again
• Blocking error: on most events you see the hook's feedback. When the hook's JSON made a blocking decision, the feedback is the reason from that decision; otherwise it is the hook's stderr. On a few events, such as ConfigChange and Elicitation, a block surfaces no message.
• Non-blocking error: the action proceeded, and you see a <hook name> hook error notice with a short explanation, such as the first line of stderr prefixed with Failed with non-blocking status code:, or a JSON validation or parse message.

Which exit-code and JSON combinations produce each outcome, including the per-event exceptions, is defined in the reference's Exit code output section.

For full execution details including which hooks matched, their exit codes, stdout, and stderr, read the debug log. Start Claude Code with claude --debug-file /tmp/claude.log to write to a known path, then tail -f /tmp/claude.log in another terminal. If you started without that flag, run /debug mid-session to enable logging and find the log path.