claude -p ignored what I piped in: "no stdin data received in 3s"

You pipe something into Claude Code, like git diff origin/main | claude -p "review this", and the answer is about nothing in particular. Above it, easy to miss in a log:

Warning: no stdin data received in 3s, proceeding without it. If piping from a slow command, redirect stdin explicitly: < /dev/null to skip, or wait longer.

claude -p waits 3 seconds for the first bytes on stdin. If the command on the left is still working and hasn't printed anything yet, Claude goes ahead with just the prompt. The exit code is 0 either way. We tested it with Claude Code 2.1.318.

See it happen#

A command that takes 5 seconds before it prints anything:

(sleep 5; echo "The secret word is pumpkin.") \
  | claude -p "Using only the piped input (do not use any tools), what is the secret word? Say NO INPUT if nothing was piped." --tools ""
echo "exit=$?"

Warning: no stdin data received in 3s, proceeding without it. If piping from a slow command, redirect stdin explicitly: < /dev/null to skip, or wait longer.
NO INPUT
exit=0

The warning goes to stderr, so in a script that keeps only stdout, or a cron job that mails only the answer, you never see it.

It's only the first bytes#

The same command with one line printed straight away:

(echo "header"; sleep 6; echo "The secret word is pumpkin.") \
  | claude -p "Using only the piped input (do not use any tools), what is the secret word? Say NO INPUT if nothing was piped." --tools ""

The secret word is **pumpkin**.

Once anything arrives, Claude reads to the end, however long the rest takes. So npm test | claude -p … is usually fine, because npm prints its > demo@1.0.0 test line at once. The ones that bite are commands that stay silent while they work:

• git fetch && git diff origin/main on a slow network
• curl -s against a slow API
• a test runner in quiet mode, or 2>/dev/null hiding its progress
• find or grep -r over a big tree that matches late

Fix: save the output first#

Run the slow command to a file, then give Claude the file:

npm test > test-output.txt 2>&1
claude -p "Which test failed and with what values? Answer in one line." < test-output.txt

`total()` failed: expected 30 but got 3.

A file is there in full the moment Claude opens it, so there is no wait to lose. It also leaves you the exact input Claude saw, which helps when the answer looks wrong.

If you'd rather not leave a file around, capture the output in a variable and pipe that:

out=$(sleep 5; echo "The secret word is pumpkin.")
printf '%s\n' "$out" | claude -p "What is the secret word?"

That worked too: by the time the pipe starts, the output already exists.

No input at all? Say so#

The warning's other suggestion is for scripts that pipe nothing: add < /dev/null so Claude doesn't sit waiting for input that will never come.

claude -p "Summarise yesterday's commits." < /dev/null

Catch it in a script#

Because the run still succeeds, nothing downstream notices. Two cheap guards:

• Keep stderr in the log (2>&1 or 2>>errors.log) and alert on no stdin data received.
• Write the input to a file and check it isn't empty before calling Claude: [ -s test-output.txt ] || exit 1.

Our post on claude -p runs that exit 0 but did nothing has a wrapper that checks the rest of the result too.

A nightly review that can't miss its input#

Putting it together: a script that reviews a branch against main every night. Save it as review.sh and call it with the project folder, from cron or by hand. The slow part (git fetch) finishes before Claude starts, the diff goes through a file, an empty diff stops the run, and stderr goes to its own log so the warning can't hide:

#!/bin/sh
cd "${1:?usage: review.sh <project folder>}" || exit 1
git fetch -q origin
git diff origin/main > review-input.txt
if [ ! -s review-input.txt ]; then echo "nothing to review"; exit 0; fi
claude -p "Review this diff for bugs. One line per problem, with file and line." \
  < review-input.txt > review.txt 2>> review-errors.log

We ran it on a branch that changed a + b to a - b:

math.js:2 — `total` now returns `a - b` instead of `a + b`, so it subtracts and no longer computes a total. Change it back to `a + b`.

On main itself, with nothing to compare, it printed nothing to review and never called Claude. Add review-input.txt and the two output files to .gitignore so they don't end up in a commit.

The same shape works for anything slow: test output, logs pulled from a server, an API response. Get the whole thing into a file, check it isn't empty, then hand it over. If the answer ever looks off, review-input.txt is still there, so you can see exactly what Claude was given instead of guessing whether the pipe was the problem.

Running it for a team#

When several people schedule agent jobs, a run that quietly reviewed nothing is easy to miss. Joxo lists every agent session on your team's computers with what it's doing, so a job that finished in seconds instead of minutes stands out. See running Claude Code on a schedule.

Frequently asked questions#

What does "no stdin data received in 3s, proceeding without it" mean?#

claude -p waited 3 seconds for piped input, got nothing, and ran with only the prompt. The command on the left of the pipe was too slow to print its first line.

Why did claude -p ignore my piped input?#

The piped command printed nothing in the first 3 seconds. Save its output to a file first and run claude -p "…" < file.txt, or capture it in a variable and pipe that.

Does claude -p fail when the piped input is missing?#

No. It exits 0 and answers the prompt alone. The only sign is the warning on stderr.

How do I stop the stdin warning in a script?#

If the script pipes nothing in, add < /dev/null to the claude -p command so it doesn't wait for input.

Does claude -p wait for the rest of a slow pipe?#

Yes, once the first bytes arrive. In our test a command printed one line, waited 6 seconds, then printed the rest, and Claude read all of it. Only a command that prints nothing for the first 3 seconds loses its input.