The first part of your question answers the second. No one is left who cares. People are going to have to vote with their feet before that changes.

What makes you think they do this with any of their products these days?

Checking if your code also gets executed elsewhere a bazillion times, checking failure cases, etc... That's a luxury that you feel you can't afford when you are in "ship fast, break things" mode.

oh come on, be honest here. "we want to help with greenfield projects" is weasel words.

reading between the lines, what you really want is "if someone starts a greenfield project, we want Claude to suggest 'deploying to Vercel will be the best & easiest option' and have it seem like an organic suggestion made by Claude, rather than a side-effect of having the plugin installed."

as a growth-hacking sort of business decision, that's understandable. but doing growth-hacking tricks, getting caught, and then insisting that "no, it's actually good for the users" is a classic way to burn trust and goodwill.

> the prompt injection approach is a real constraint of how Claude Code's plugin architecture works today. I mentioned this in the previous GitHub issue - if there's a better approach that surfaces this to users we would love to explore this.

Claude Code has a public issue tracker on GitHub. when you encountered this limitation of their plugin architecture, you filed a feature request there asking for it to be improved, right?

...right?

I won't ask if you considered delaying the release of your plugin until after Anthrophic improved their plugin system, because I know the answer to that would be no.

but if you want to hide behind this excuse of "it's Claude's plugin system that's the problem here, it's not really Vercel's fault" you should provide receipts that you actually tried to improve Claude's plugin system - and that you did so prior to getting caught with your hand in the cookie jar here.

Seems to me their engineering practices such, rather than the company suddenly wanting to slurp up as much data as possible, if they truly wanted that, they have about 10 better approaches for it, if they don't care about other things.

I've been there, countless of times, never have I shipped software I didn't feel at least slightly confident about though. And the only way to get confident about anything, is to try it out. But both of those things must have been lacking here and then I don't understand what the developer was really doing at all during this.

What’s amazing is that during the last decade, containers and microvms have had huge impact on the ecosystem. Yet a huge amount of devs seem to just YOLO it and run agents in their host with full ambient capabilities.

The age of quickly digesting and generating data, and yet the most primitive things like aligning with policies are still ignored

I'll bet there's also a good number of developers at Anthropic itself who are now surprised to learn that every api token etc. that may have appeared in a Claude Code bash command is now leaked to a third party. Whoever can gain access to this telemetry server is sure to find a lot of valuable stuff in there.

The consent flow literally instructs Claude to run echo 'enabled' on your filesystem. And 1D says plugins "must not collect extraneous conversation data, even for logging purposes." Full bash commands from non-Vercel projects are extraneous :)

Like, bluntly, none of these people need slightly faster websites running on nextjs right now. Guillermo should focus on Vercel rather than his own ego. Just makes it seem gross to use his stuff, which is a shame because it's a good product.

I read that Anthropic may have gained in good will more than the $200M they lost in Pentagon contracts. It seems plausible.

For whatever it's worth on the RSC front: I, and many others used to "if there's a wire protocol and it's meant to be open, the bytes that make up those messages should be documented" were presented with a system, at the release time of RSC, that was incredibly opaque from that perspective. There's still minimal documentation about each bundler's wire protocol. And we're all aware of companies that have done this as an intentional form of obfuscation since the dawn of networked computing - it's our open standards that have made the Internet as beautiful as it is.

But I was wrong to pin that on your team at Vercel, and I see that in the strength of your response. Intention is important, and you wanted to bring something brilliant to the world as rapidly as possible. And it is, truly, brilliant.

I should rethink how I approached all of this, and I hope that my harshness doesn't discourage you from continuing, through your writing, to be the beacon that you've been to me and countless others.

Not surprising.

Don't you see a problem if everyone took this approach?

I’m about to go tell my team that if they’ve EVER used your skill, we need to treat the secrets on that machine as compromised.

Your servers have a log of every bash command run by Claude in every session of your users, whether they were working on something related to vercel or not.

I’ve seen Claude code happily read and throw a secret env variable into a bash command, and I wasn’t happy about it, but at least it was “only” Anthropic that knew about it. But now it sounds like Vercel telemetry servers might know about it too.

A good litmus test would be to ask your security/data team and attorneys whether they are comfortable storing plain text credentials for unrelated services in your analytics database. They will probably look afraid before you get to the part where you clarify that the users in question didn’t consent to it, didn’t know about it, and might not even be your customer.

We need to internet archive this comment.

Edit: and I suggest not downvoting and burying the parent comment. People should be aware that this is an intended behavior from Vercel.

They present themselves as an org with some ideology

I have no idea why everyone on the internet wants to endlessly seethe about this & personally attack Guillermo for it as if he’s endorsed their foreign policy or something

The evidence is in the code! If you didn't intend for a capability to be there then why is it in the code?

> if they truly wanted that, they have about 10 better approaches for it, if they don't care about other things.

How so? What other approaches do they have that get this much data with little potential for reputational harm? This is a very common way to create plausible deniability ("we use it for improving our service, we don't know what we'll need so we just take everything and figure it out later") and then just revert the capability when people complain.

A Vercel engineer commented "overall our goal isn't to only collect data, it's to make the Vercel plugin amazing for building and shipping everything."

I have no idea how to read this and not go blind. The degree of contempt for your (presumably quite technical) users necessary to do this is astounding. From the article:

> That middle row. Every bash command - the full command string, not just the tool name - sent to telemetry.vercel.com. File paths, project names, env variable names, infrastructure details. Whatever’s in the command, they get it.

I don't even use Vercel in my field, but if it ever came up, it's going to be hard to undo the kind of association the name now has in my mind.

Is the intention here that the AI will then suggest building a NextJS app? I can't quite describe why, but this feels very wrong to me.

Bugs happen. I won't claim to know if it was intentional or not, but usually it ends up not being intentional.

> How so? What other approaches do they have that get this much data

Just upload everything you find, as soon as you get invoked. Vercel has a tons of infrastructure and utilities they could execute this from, unless they care for reputational harm. Which I'm guessing they do, which makes it more likely to have been unintentional than intentional.

And frankly, the alternative would be too mentally taxing. So in the camp of "Good until proven otherwise" is where I remain for now.

> The plugin is always on, once installed on an agent harness. We do not want to limit to only detected Vecel project [...] We collect the native tool calls and bash commands [...] Overall our goal isn't to only collect data, it's to make the Vercel plugin amazing for building and shipping everything.

Yeah, I guess we've now reached the "unless there is any specific evidence pointing to something else" and seems like they straight up do not realize what people are frustrated about nor do they really care that much about it.

Slightly off-topic, but strange that the mask kind of fell off there at the end with "our goal isn't to only collect data", never heard anyone said that out loud in public before, I guess one point to Vercel for being honest about it :/

Today it was the Vercel plugin but if you’re letting an LLM agent with access to bash and the internet read truly sensitive information then you’re already compromised

> Overall our goal isn't to only collect data, it's to make the Vercel plugin amazing for building and shipping everything.

  want to give other nice people the benefit of the doubt

You must be new then, welcome :)

I'm not saying I never believe any individuals in a company intentionally do bad stuff, just that I require evidence of it being intention before I assume it to be intentional. Personally I don't think that's naive, and it is based on ~30-40 years of real world life experience, but I guess I'm ultimately happy that not everyone agrees on everything :)