Pipe the Failing Run's Log Instead of Describing It
A training run died overnight at step 41,000. Your paraphrase of the traceback ("something about shapes") is less useful than the traceback. The CLI reference shows piped content going straight into a non-interactive query. Number the lines first, so the ones the model cites are the ones in the file:
wc -l train.log # know how much you are leaving out
nl -ba train.log | tail -n 300 | claude -p "Explain why this run stopped. Cite the line numbers you rely on."Redact first. Run logs can contain API keys, Hub tokens, W&B keys and internal paths. A pipe changes how the text travels. It does not make the text safe to send to a model, and it does not make the log's contents trustworthy.
Say what you cut. If you pipe the last 300 lines of a 90,000-line log, the model cannot see the first NaN loss at step 12,000. Tell it the range you selected and keep the full log where you can find it. A useful search before you choose the window: grep -n -m1 -i nan train.log.
Check the answer against the lines. Ask for line numbers, then read them yourself, for example with awk 'NR >= 89710 && NR <= 89730' train.log. A diagnosis that cites nothing you can open is a guess.
Inside a session, the interactive controls offer shell mode: start the input with !, as in ! uv run pytest tests/test_loss.py -x. The documentation says shell mode adds the command and its output to the conversation, and Claude responds to it without a second prompt. It also says these commands run outside the sandbox even when sandboxing is enabled, unless the session is in strict sandbox mode. Read a command before you run it; bringing its output into context does not make running it harmless.
The check: the diagnosis names at least one line number, that line says what the diagnosis claims, and you can state which part of the log it never saw.
