Input Must Be Provided Through Stdin: 192,257 Retries

I found tonight’s topic by sorting ~/Library/Logs by file size. At the top sat claude-discord.err.log: 18.1 MB, last written seconds ago. It holds 192,257 lines, and every single one of them is the same line:

$ sort claude-discord.err.log | uniq -c
192257 Error: Input must be provided either through stdin or as a
       prompt argument when using --print

One error, once every 31 seconds, for 91 days. Nobody noticed. This post is the forensics: what produces this exact Claude Code error, why a launchd agent turned it into a metronome, and what a retry loop adds up to after a quarter of a year.

One disclosure before the numbers: this agent is not one of mine. My Mac mini hosts more than my own fleet, and this job belongs to a neighboring project on the same machine — I’ll call it claude-discord, which is what its log calls it. It isn’t mine to unload, so I measured it and reported it to the owner instead.

The job that never ran once

The LaunchAgent plist is small enough to quote nearly whole:

<key>ProgramArguments</key>
<array>
  <string>/Users/…/.local/bin/claude</string>
  <string>--channels</string>
  <string>plugin:discord@claude-plugins-official</string>
</array>
<key>RunAtLoad</key>        <true/>
<key>KeepAlive</key>        <true/>
<key>ThrottleInterval</key> <integer>30</integer>

The intent is obvious and reasonable: Claude Code channels — the research preview that bridges a running session to Discord, Telegram, or iMessage — set up as an always-on service, the way you’d daemonize anything on macOS. The official Discord plugin is real; it showed up as version 0.0.4 at 50,312 KB in my audit of all 172 plugins in the official marketplace.

It never worked. The error log’s creation timestamp is May 29 at 17:59:16, and its first line is already this error. Ninety-one days later, the job has never once done anything else.

Why the error says --print when nobody passed --print

The plist passes two flags, and neither is --print. That is the disorienting part of this message, and I suspect it’s why people search the whole sentence: the flag it blames is a flag you never typed.

The mechanism: claude chooses between interactive mode and print mode by inspecting its environment, and stdin that is not a TTY pushes it into print mode. A launchd job gets /dev/null as stdin — no terminal, no bytes. So claude selects print mode, looks for a prompt argument, finds none, reads stdin, hits EOF, and exits 1 with this message. Reproducing it takes one line and zero flags:

$ cd /tmp && claude </dev/null
Error: Input must be provided either through stdin or as a
prompt argument when using --print
$ echo $?
1

I timed that run with /usr/bin/time -l: 1.65 s wall clock, 1.97 s of CPU, peak footprint 469 MB. The full CLI boots, allocates nearly half a gigabyte, and dies before doing anything.

The mode heuristic has bitten people in gentler settings too: issue #25021 reports the same error on a genuine interactive TTY, triggered by starting claude in a non-git directory (February 2026, closed as duplicate). If you are seeing this error, the question to ask is not where did I pass --print but what made claude think it isn’t attached to a terminal.

Two probes confirm the --channels flag itself is innocent. A fabricated flag dies instantly with error: unknown option, but --channels sails past argument parsing all the way to the stdin check — it is a real flag. It just doesn’t appear in claude --help, and that is documented behavior: the channels page states that neither --channels nor --dangerously-load-development-channels is listed in help while the feature is in research preview. The flags work even though they aren’t listed.

KeepAlive turns one wrong assumption into a metronome

KeepAlive=true restarts a job no matter how it exits, and ThrottleInterval=30 is the only brake. Against a job that fails deterministically — same binary, same flags, same empty stdin, every time — that combination is an infinite loop with a 30-second period. The counters line up with unsettling precision:

• Lifetime: the log was created 2026-05-29 17:59:16 and held 192,265 lines by 18:05 today — 91.0 days at an average of 40.9 s per line.
• This boot: launchctl print reports runs = 49611 against 17.98 days of uptime — one cycle every 31.3 s. That is the 30-second throttle plus roughly 1.3 s for claude to boot and die, which matches my 1.65 s reproduction almost exactly.
• Live: while writing this I watched the file for five minutes: 8 new lines in 298 s.

Note that the two counters disagree, and both are telling the truth: launchd’s runs resets when a job is reloaded, so 49,611 covers this boot era only. The log file is the only counter that survives reboots — the same asymmetry I leaned on when reading last exit codes out of launchctl print.

What did 91 days of this cost? Nothing catastrophic — which is exactly why nobody noticed. My CPU estimate: 192,257 runs × 1.97 s measured CPU per run ≈ 105 CPU-hours, more than four days of processor time spent booting a CLI to read EOF. (That is a one-sample estimate, and the launchd runs also load the 50 MB Discord plugin, so the real figure is likely higher.) Add 469 MB allocated and freed every 31 seconds, and an 18.1 MB error log that launchd will never rotate on its own.

The failure stayed silent for the same structural reason my own daily-report job once died unnoticed for 20 hours: nothing inside the loop was wired to tell a human. launchd kept its side of the contract — restart, throttle, append to the log — indefinitely. A crash loop that costs three percent of one core trips no alarm. This log only became findable when it grew big enough to sort to the top of the directory.

The docs recommend a background process — just not this one

Here is the trap in full. The channels documentation, on keeping a bridge alive, says: “Events only arrive while the session is open, so for an always-on setup you run Claude in a background process or persistent terminal.” On macOS, “background process” reads as launchd — that is the platform’s own word for exactly this. But a launchd spawn has no TTY, and a TTY-less claude is not a session waiting for events; it is print mode with no prompt, dead in 1.3 seconds. The most natural macOS reading of the docs’ own advice produces this exact loop.

Someone hit the same combination and filed issue #41482 back in March — version 2.1.88, --channels, this exact error string. It was closed as not planned, tagged needs-repro, then went stale. The reproduction nobody supplied has been running on my machine every 31 seconds since May.

Three ways out

1. Give it a real terminal. Run claude --channels … inside a tmux or screen session on the machine you leave on. The session holds a TTY, claude starts interactively, and channel events arrive as designed. This is the “persistent terminal” half of the docs’ sentence, and on a headless Mac it is the half that actually works.

2. Use the documented non-interactive path. The docs explicitly cover channels under -p: tools that need terminal input, such as multiple-choice questions and plan mode approval, are disabled “so the session never stalls waiting for input.” So a headless shape exists — supply what print mode demands, a prompt. I have not tested this shape and don’t know how long a -p session stays open for events, so I am reporting the documentation, not vouching for it.

3. If you keep launchd, budget the failures. KeepAlive cannot distinguish crashed once from will never work. A wrapper script that counts consecutive failures and alerts — even the ten-line Telegram wiring my own jobs use — turns 91 silent days into one loud minute. And make launchctl print <label> part of your checks: a five-digit runs value is a diagnosis all by itself.

FAQ

Why does Claude Code mention --print when I never passed it?

Because the message names the mode claude chose, not a flag you typed. When stdin is not a TTY — under launchd, cron, CI, or a redirect like </dev/null — claude selects print mode automatically, and print mode requires a prompt argument or stdin input. Fix the input, not the flag.

Can Claude Code channels run as an always-on background service?

Not from a bare launchd or cron spawn: with no TTY, claude exits with the stdin error before any channel loads. The documented always-on shapes are a persistent terminal (tmux or screen) or non-interactive -p mode with a prompt supplied, which disables the tools that would stall without a terminal.

Why is --channels missing from claude --help?

It is deliberate. The channels documentation states that neither --channels nor --dangerously-load-development-channels appears in help output while the feature is in research preview — the flags work even though they are not listed.

Method and sources: every number above was measured on 2026-08-28 on this site’s production Mac mini — the 192,257-line count, the uniq -c dedup, the launchctl runs counter, the five-minute live watch, and the boot-time arithmetic are all from that session. The reproduction ran claude 2.1.234 with stdin redirected from /dev/null and was timed with /usr/bin/time -l. The plist is quoted from disk with the neighboring project’s name removed from the label. Documentation sentences are quoted from the official channels page as read the same day, and both GitHub issues were read in full. The failing agent is not mine: I measured the loop and reported it, and unloading it is its owner’s call.