381–390 of 431 posts
You can find the revamped prompt on github[1], or on twitter summarized by my bot[2]. [1] https://github.com/marckrenn/cc-mvp-prompts/compare/v1.0.128... [2] https://x.com/CCpromptChanges/status/1972709093874757976
How are these reliably extracted (hint: they’re not)
I wrote about one tool for doing that here: https://simonwillison.net/2025/Jun/2/claude-trace/
Something I realized about this category of tool (I call them "terminal agents" but that already doesn't work now there's an official VS Code extension for this - maybe just "coding agents" instead) is that they're actually an interesting form of general agent . Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer. They're incredibly dangerous to use if you d…
Earlier quoted context omitted.
I'm a recent jj convert, and working with llms was actually a driver for my own jj adoption. I haven't tried the watch daemon, but I do run `jj new` anytime i ask the llm agent to do anything. It has worked amazingly well.
I automated that with some simple claude hooks that detect if we're in a `jj` repo and also prompts claude to `jj commit -m` after every change.
Earlier quoted context omitted.
You've been safe since launch because you haven't faced an adversarial prompt injection attack yet. You (and many, many others) likely won't take this threat seriously until adversarial attacks become common. Right now, outside of security researcher proof of concepts, they're still vanishingly rare. You ask why I'm obsessed with the danger? That's because I've been tracking prompt injection - and our total failure t…
how are you going to get "adversarial attacks" with prompt injection. If you don't fetch data from external sources. Web scraping ( you can channel that thru Perplexity by the to sanitize it). PR reviews, would be fine if repo is private. I feel this is overly exagerated here. There is more issues that are currently getting leverage to hack with vscode extension than AI prompt injection, that require a VERY VERY comp…
The researcher has gotten actual shells on oai machines before via prompt injection
Earlier quoted context omitted.
how are you going to get "adversarial attacks" with prompt injection. If you don't fetch data from external sources. Web scraping ( you can channel that thru Perplexity by the to sanitize it). PR reviews, would be fine if repo is private. I feel this is overly exagerated here. There is more issues that are currently getting leverage to hack with vscode extension than AI prompt injection, that require a VERY VERY comp…
If you don't fetch data from external sources then you're safe from prompt injection. But that's a very big if . I've seen Claude Code attempt to debug a JavaScript issue by running curl against the jsdelivr URL for a dependency it's using. A supply chain attack against NPM (and those aren't exactly rare these days) could add comments to code like that which could trigger attacks. Ever run Claude Code in a folder tha…
Again you likely use vscode. Are you checking each extension you download? There is already a lot of reported attacks using vscode.
A lot of noise over MCP or tools hypothetical attacks. The attack surface is very narrow, vs what we already run before reaching Claude Code.
Yes Claude Code use curl and I find it quite annoying we can't shut the internal tools to replace them with MCP's that have filters, for better logging & ability to proxy/block action with more in depth analysis.
Earlier quoted context omitted.
how are you going to get "adversarial attacks" with prompt injection. If you don't fetch data from external sources. Web scraping ( you can channel that thru Perplexity by the to sanitize it). PR reviews, would be fine if repo is private. I feel this is overly exagerated here. There is more issues that are currently getting leverage to hack with vscode extension than AI prompt injection, that require a VERY VERY comp…
> how are you going to get "adversarial attacks" with prompt injection Lots of ways his could happen. To name two: Third-party software dependencies, HTTP requests for documentation (if your agent queries the Internet for information). If you don't believe me, setup a MITM proxy to watch network requests and ask your AI agent to implement PASETO in your favorite programming language, and see if it queries https://git…
More seen as buzz article about how it could happen. This is very complicated to exploit vs classic supply chains and very narrow!
Earlier quoted context omitted.
> how are you going to get "adversarial attacks" with prompt injection Lots of ways his could happen. To name two: Third-party software dependencies, HTTP requests for documentation (if your agent queries the Internet for information). If you don't believe me, setup a MITM proxy to watch network requests and ask your AI agent to implement PASETO in your favorite programming language, and see if it queries https://git…
This is a vendor selling a solution for "hypothecal" risk not seen in the WILD! More seen as buzz article about how it could happen. This is very complicated to exploit vs classic supply chains and very narrow!
????
What does "This" refer to in your first sentence?
Earlier quoted context omitted.
That is nice, but it makes me wonder how little people actually know and use git nowadays. This is after all, something git really shines at. Still good to see! (It's not like I can't still just use git for that, which I fully intend to do)
That was my first thought too - but this is subtly different, and rewinds the context too. Actually highly useful, because I have often felt like a bad first pass at a solution poisoned my context with Claude.
Earlier quoted context omitted.
Instead of containers, which may not always be available, I'm experimenting with having control over the shell to whitelist the commands that the LLM can run [0]. Similar to an allow list, but configured outside the terminal agent. Also trying to make it easy to use the same technique in macOS and Linux [0]: https://ricardoanderegg.com/posts/control-shell-permissions-...
I didn’t check, but sometimes Claude Code writes scripts and run them (their decision); does your approach guard against that?
Earlier quoted context omitted.
Instead of containers, which may not always be available, I'm experimenting with having control over the shell to whitelist the commands that the LLM can run [0]. Similar to an allow list, but configured outside the terminal agent. Also trying to make it easy to use the same technique in macOS and Linux [0]: https://ricardoanderegg.com/posts/control-shell-permissions-...
I really like this and we're doing a similar approach but instead using Claude Code hooks. What's really nice about this style of whitelisting is that you can provide context on what to do instead; Let's say if `terraform apply` is banned, you can tell it why and instruct it to only do `terraform plan`. Has been working amazing for me.