Posted by takira 1/14/2026
For a programmer?
I bet 99.9% people won't consider opening a .docx or .pdf 'unsafe.' Actually, an average white-collar workers will find .md much more suspicious because they don't know what it is while they work with .docx files every day.
Never understood why that became so common place ...
I wish you were wrong.
I think the truly average white collar worker more or less blindly clicks anything and everything if they think it will make their work/life easier...
*.dmg files on macOS are even worse! For years I thought they'd "damage" my system...
Well, would you argue that the office apps you installed from them didn't cause you damage, physically or emotionally?
The instruction may be in a .txt file, which is usually deemed safe and inert by construction.
You can even add a nice "copy to clipboard button" that copies something entirely different than what is shown, but it's unnecessary, and people who are more careful won't click that.
You’re only going to ever get a read only version.
1: I wish they didn't, because my Github is way more interesting than my professional experience.
Subsequent modifications would of course invalidate any digital signature you’ve applied, but that only matters if the recipient cares about your digital signature remaining valid.
Put another way, there’s no such thing as a true read-only PDF if the software necessary to circumvent the other PDF security restrictions is available on the recipient’s computer and if preserving the validity of your digital signature is not considered important.
But sure, it’s very possible to distribute a PDF that’s a lot more annoying to modify than your private source format. No disagreement there.
It requires a proper PDF viewer.
It works for a lot of other providers too, including OpenAI (which also has file APIs, by the way).
https://support.claude.com/en/articles/9767949-api-key-best-...
https://docs.github.com/en/code-security/reference/secret-se...
Obviously you have better methods to revoke your own keys.
agreed it shouldn't be used to revoke non-malicious/your own keys
If it's a secret gist, you only exposed the attacker's key to github, but not to the wider public?
So the prompt injection adds a "skill" that uses curl to send the file to the attacker via their API key and the file upload function.
Assuming that they took any of your files to begin with and you didn't discover the hidden prompt
Moreover, finding a more effective way to revoke a non-controlled key seems a tall order.
Storage is actually not much of a problem (on your end): you can just generate them on the fly.
GitHub and their partners just see a secret and trigger the oops-a-wild-secret-has-appeared action.
Unlike /slash commands, skills attempt to be magical. A skill is just "Here's how you can extract files: {instructions}".
Claude then has to decide when you're trying to invoke a skill. So perhaps any time you say "decompress" or "extract" in the context of files, it will use the instructions from that skill.
It seems like this + no skill "registration" makes it much easier for prompt injection to sneak new abilities into the token stream and then make it so you never know if you might trigger one with normal prompting.
We probably want to move from implicit tools to explicit tools that are statically registered.
So, there currently are lower level tools like Fetch(url), Bash("ls:*"), Read(path), Update(path, content).
Then maybe with a more explicit skill system, you can create a new tool Extract(path), and maybe it can additionally whitelist certain subtools like Read(path) and Bash("tar *"). So you can whitelist Extract globally and know that it can only read and tar.
And since it's more explicit/static, you can require human approval for those tools, and more tools can't be registered during the session the same way an API request can't add a new /endpoint to the server.
It's like customizing your text editor or desktop environment. You can do it all yourself, you can get ideas and snippets from other people's setups. But fully relying on proprietary SaaS tools - that we know will have to get more expensive eventually - for some of your core productivity workflows seems unwise to me.
[0] https://news.ycombinator.com/item?id=46545620
[1] https://www.theregister.com/2025/12/01/google_antigravity_wi...
> It won't be quite as powerful as the commercial tools
If you are a professional you use a proper tool? SWEs seem to be the only people on the planet that rather used half-arsed solutions instead of well-built professional tools. Imagine your car mechanic doing that ...
But for everyone else I think it's important to find the right balance in the right areas. A car mechanic is never in the business of building tools. But software engineers always are to some degree, because our tools are software as well.
There is a size of tooling thats fine. Like a small script or simple automation or cli UI or whatever. But if we're talking more complex, 95% of the times a stupid idea.
PS: of course car mechanics built their tools. I work on my car and had to build tools. A hex nut that didn't fit in the engine bay, so I had to grind it down. Normal. Cut and weld an existing tool to get into a tight spot. Normal. That's the simple CLI tool size of a tool. But no one would think about building a car lift or a welder or something.
> take a half working open source project
See, how is that appropriate in any way in a work environment?
Who has time to mess around with all that, when my employer will just pay for a ready-made solution that works well enough?
Eg Mario Zechner (badlogic) hit it out of the park with his increasingly popular pi, which does not flicker and is VERY hackable and is the SOTA for going back to previous turns: https://github.com/badlogic/pi-mono/blob/main/packages/codin...
That's just Anthropic's excuse. Literally no other agentic AI TUI suffers from flickers, esp. on tmux Claude Code is unusable.
I've written my own agent for a specialised problem which does work well, although it just burns tokens compared to Cursor!
The other advantage that Claude Code has is that the model itself can be finetuned for tool calling rather than just relying on prompt engineering, but even getting the prompts right must take huge engineering effort and experimentation.
None of them ever even tried to delete any files outside of project directory.
So I think they're doing better than me at "accidental file deletion".
The level of risk entailed from putting those two things together is a recipe for diaster.
Oh, no, another "when in doubt, execute the file as a program" class of bugs. Windows XP was famous for that. And gradually Microsoft stopped auto-running anything that came along that could possibly be auto-run.
These prompt-driven systems need to be much clearer on what they're allowed to trust as a directive.