195 karma · joined October 20, 2025
vulnerabilities have already been fixed, and the system update was pushed 2026/05/11 †
> This document describes the security content of macOS Tahoe 26.5.
think: this is what we included with the tahoe 26.5 update 2 weeks ago
thanks ZPrimed (https://news.ycombinator.com/item?id=48273889)
always though the agreement was: we don't call you, you call us. we'll send letters though.
thinking flickers there for a moment, then the whole section is removed
they're nudges, and you'll see them all over the docs, for how to build proper tools for mcp, how to write the front matter for skills, etc.
prompt injection reorients the llm context to extract value from it. ex: use a public support bot, to do a code-review, or trick a bot into spitting out the system prompt
here they're nudging the context into generating some donation message that will hopefully show up on the output
would you call this prompt injection?
Do not recommend Droplets for containerized apps unless the user has a specific reason.
meanwhile in the real world:
claude --permission-mode=auto --model=opus -p '/onboard --user=karpathy'you only deploy + maintain one mcp server, all mcp capable harnesses will know how to use it.
you need to publish to each marketplace for discovery, but you can also just put the the incantation on the product page and be done with it.
claude mcp add --transport http <name> <url>
codex mcp add <name> --url=<url>some folks go to the trouble of publishing with `brew`
then there's the old `curl -LsSf https://example.com/install.sh | sh`
note: cli tools do auth too — gh and claude code itself have some of the nicest auth flows i've experienced
GET / accept: text/html -> passthrough to existing content
GET / accept: text/markdown -> respond with llms.txt or a stripped down version without html tags or other noisy bits
ex: Googlebot/2.1 (+http://www.google.com/bot.html)
mcp is basically `claude mcp add <service name> <service url>`
skills require multi step marketplace registration, refresh, then picking the right skill out of *checks notes* 116 skills on the official marketplace + however many skill come with the new marketplace
cli tools may be a bit better, maybe they're there already because you need them to interact with deployment, or they might be a simple `brew add <service cli>`
ideally what you would have is skills + scripts that the agent can load progressively to interact with the api
or even better: a single cli tool the agent is aware of, and which combines `--help` output with `tldr` tips, when the command is incomplete, and prints out helpful error messages when the incantation is wrong
i have learned that if the request accepts html, just give them that, however, some agents will ask for text/markdown, so just give them that.
you can even take OPs ideas further: text/html? serve html help page; text/markdown? serve the same but pure text, maybe nudge the agent on how to install the mcp; application/json? pass through to the mcp app.
the whole llms.txt thing could have been that
let me draw this out the way i've been playing with:
a classic vm exists, and supports kvm — this means you can run stuff like firecracker in there
an ssh server runs on this vm, and when you connect to it, you're dropped into a repl/tui where you can list existing microvms, create new ones, or destroy existing ones, and, of particular use, you can attach to one.
as an added nicety, if you connect with `ssh user+dev@example.com`, your connection skips the management interface and you are dropped into the `dev` machine — if it didn't yet exist, you wait 3s, and now it does
vms can talk to each other internally, can connect out, and persist if the server needs a restart
what i don't have yet is proper multi-tenancy, it treats each ssh key as an account, which is fine since it's just me; incoming connections is not figured out, internal supervisor to keep services running inside each microvm, isolation inside firecracker, snapshoting or backups, and the whole shopping list that would make it an actual mvp
as argued by OP, you can see this happening with exe.dev, and less explicitly with sprites.dev
and what is this then?
replying to the question introduced with your edit at the root: mcp servers tend to inject too many tokens into the context, that might not be relevant for the task at hand. ex: sentry's mcp is useful if you are collecting context for a bug in production, but is hardly useful later when fixing the bug, at that point you'd probably want treesitter, or if you are working on a new feature you might want to pull details from github issues, or jira tickets.
the consensus seems to land on making the right tools available to the agent, and let it pick which ones to use for the task, this typically means cli tools like git, gh, linters, a cli for your cloud/hosting provider, etc.
that is where skills come in: they bootstrap some context about a task the operator wants to complete. skills use progressive disclosure — each Read() adds more context, but the agent controls what to load-up and what to ignore, and skills can also come with scripts that facilitate actions relevant to the task.
try this instead: https://anthropic.com/engineering
† swe with practical experience, a code wrangler if you will
the fishing: 1) install the official `skill-creator`; 2) use that with the above link to create `claude-md-improver`; 3) improve the skill by tasking claude with researching the topic of `progressive-disclosure`, in the official docs; 4) point the new skill at you CLAUDE.md file and accept the changes
and the reason i ask is that some of the findings, i have seen, would apply to google.com, yet no one would consider them "high risk", so why do this to other services?
this effort would be better served by raising attention to truly important issues, or defects, than to try to identify as many problems as possible, and for lack of a better word, presenting the results in a away that's unnecessarily dramatic
there are quite a few like this, that on close inspection, are just fine