[BUG]: CLI error with system prompt and doesn't recognize permissions
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 12 comments · opened Aug 1, 2025 · closed Apr 1, 2026
time claude --mcp-config "" --strict-mcp-config --model opus --debug --system-prompt "Do you have permission to use the bash tool?" -pError: Input must be provided either through stdin or as a prompt argument when using --print
---
I did provide the --system-prompt field, which works in other cases. I get the same error with --append-system-prompt.
Incidentally, the --system-prompt argument appears to work, but does not show up in the --help documentation.
---
Another bug: Claude does not recognize permissions. Look at this:
claude --mcp-config "" --strict-mcp-config --model opus --debug -p "Do you have permission to use the bash tool?"
Yes, I have permission to use the bash tool.
time claude --mcp-config "" --strict-mcp-config --model opus -p --system-prompt "Here is a large PDF. Use qpdf to extract the first page of this PDF. Then, read and summarize the first page." "mypdf.pdf"
The PDF file is too large (143.4MB) to read directly with the Read tool. I need to use qpdf to extract just the first page, which will make it small enough to read. Could you please grant permission for me to use the Bash tool so I can run the qpdf command to extract the first page?
12 Comments
Found 3 possible duplicate issues:
If your issue is a duplicate, please close it and 👍 the existing issue instead.
🤖 Generated with Claude Code
For the issue related to bash permissions, I found the solution: It really needed
Bash(qpdf:*). While it had other Bash permissions set, it didn't have that specifically.So, the error messages just needs to be more specific. As is, it was confusing. It didn't need Bash permission (which it had, said generally like that) -- it needed something more specific. A more specific error message would have prevented me from searching down the wrong path for awhile.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This is still occurring.
As per https://github.com/anthropics/claude-code/issues/6820 it can also be seen when using
op run ... -- claude(to inject secrets from 1Password). It looks likeop runpasses through stdin/stdout normally so I'm not sure why this is happening.Curiously:
So I'd imagine there's a clue in exactly what/how
opbehaves in each of these cases.Either way,
claudeis apparently behaving incorrectly for a *nix program, and it'd be extremely helpful if this could be resolved.can reproduce on osx with micromamba(conda equivalent env.)
fixed by reactivating the env.
Both with and without the env-file exhibit the same behavior for me, fwiw. Both fail.
Here's a quick workaround for now:
Per Gemini:
Confirming this is still an issue with Claude 2.1.6 via:
@bdruth 's fix does indeed work though (thank you!)
@bdruth thanks for the workaround, the main issue persists
I got it working by using the
--no-maskingflag with theopcommand.Note I am using the new environments feature with the service accounts, as I am sharing secrets with my team. I launch a new shell and run:
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.