Sidequest: The File Called Standard In, or Where Claude's Throwaway Scripts Crash

Cold open

When a traceback says "File stdin, line 10, in module", Python is telling you the code that crashed never lived in a file. Claude typed it straight into Python's input, and it fell over on its tenth line.

Why you keep seeing it

Look at what the session was doing when you asked. You had a follow-up request sitting in theassistant's inbox, and Claude wanted to know whether the service would pick it up. It did not write a proper script for that. It pulled up Python on the spot, typed a few lines that opened the ledger, imported theassistant's own request parser, pointed it at the note and printed the result. Then it threw those lines away.

Claude does this all the time. It is the quickest way to poke at a JSON state file, count rows or ask a real module a question without creating anything on disk. Most of the time the poke works and all you see is the answer. Sometimes it guesses a key name wrong, or reads a file that does not exist yet, and Python prints a traceback. Those are the moments you have been catching "here and there".

Taking the line apart

The line has 3 parts, and each one means something.

First, "stdin", short for standard input. Every program has an input pipe, and one way to hand Python code is to pour the code down that pipe. Claude does this with a shell trick called a heredoc, which in effect says "everything until the word EOF is the script". Python got its code from the pipe, so it has no filename to report, and it writes "stdin" in angle brackets. If Claude passes the code as one quoted argument instead, as most of the probes in this session did, the label becomes "string". Same idea, different delivery truck.

Second, "line 10". That counts lines from the top of the throwaway snippet, not from any file in your repos. There is no line 10 for you to go and find. It went away the moment the command finished.

Third, "in module". That means the failing line sat at the top level of the snippet, not inside a function. Quick probes are almost always flat, top-to-bottom code, so you will nearly always see "module" here.

Together: "Claude's quick improvised script tripped on its tenth line." That is all it says.

How to tell whether it matters

This is the useful part. A Python traceback is a stack, and you read it from the bottom up. The very last line is the actual complaint, something like "KeyError" or "file not found". The lines above it trace the route the code took to get there.

So here is the triage rule. If every location in the traceback says stdin or string, the crash is in Claude's own probe. That is Claude stubbing its toe on a guess, and it will normally fix the guess and run it again within the same breath. Nothing of yours broke.

If a location in the stack names a real file, say theassistant's followups module or something inside a repo, then Claude's snippet called into your real code and the real code threw the error. That one is worth paying attention to, because it is a finding about the tool and not about the probe.

The top line, the stdin one, tells you where the trip began. The bottom line tells you what actually went wrong.

The other face of the same pipe

Standard input shows up elsewhere in your estate, in a less friendly role. The harness-quirks rule has a standing warning that Codex, when run from a Claude session, has to be given an input pipe that is explicitly closed. Otherwise Codex sometimes sits waiting for input that never arrives and hangs for good. It is the same pipe as in your traceback. There it carried a script, and here it carried nothing, forever. Programs treat standard input as a door that might open, and Codex just stands there holding it.

If you remember one thing:

"File stdin" means the crash happened in a throwaway script Claude typed on the spot, so it is Claude's probe tripping. It only becomes your problem when a real filename shows up further down the traceback.