In June the interesting question about Kickbacks was economic. Can a developer get paid for the seconds an AI coding assistant spends thinking? Two months later that question has an answer, and the answer is a small number. But the number is no longer the point. An independent security review has been published since, and it moves the decision from "is this worth my attention" to "what am I installing next to my SSH keys".
This is a follow-up, written for the person who actually has to decide. If you have not read the first piece, the short version is below. If you have, skip ahead to the security section, because that is where the story changed.
The payouts are real, and they are tiny
Kickbacks now displays 121,597 dollars on its developer earnings counter. Read the label carefully: that is the company's own number, and it counts what has been earned rather than what has been withdrawn, so with a payout threshold of 10 dollars a large part of it sits on individual counters that will never reach it. Money is still moving in a way it was not in June, when payments were not live at all and Stripe Connect was described as nearly finished. Plenty of launches with 5.5 million views never ship the part where money moves at all. This one did. In June, payments were not live at all, Stripe Connect was described as nearly finished, and plenty of launches with 5.5 million views never ship the part where money actually moves. This one did.
Then you divide. The most favourable figure in circulation puts a typical month at around 40 dollars, and the only published measurement runs well below it: the same security review recorded 2.24 dollars after four days of active use, against a payout threshold of 10 dollars. Even on the generous end, that is roughly three weeks of coding with Claude every day before the first payment clears the threshold and becomes withdrawable. An independent test measured 2.24 dollars after four days of active use, against a payout threshold of 10 dollars. That is roughly three weeks of coding with Claude every day before the first payment clears the threshold and becomes withdrawable.
The arithmetic behind those figures
Why the figure is that small The rate card explains the result. An impression on a spinner is sold on a CPM basis and shared with the developer who displays it, and the published rates are the going price for attention without intention. Someone staring at a spinner is waiting for a generation to finish: not shopping, not comparing vendors, not about to click. That inventory is worth what it is worth, and no rational advertiser pays much more for it. One caution before anyone reaches for a calculator: the terms move. The revenue share announced at launch was raised after the extension was pulled from the VS Code Marketplace and republished on 25 June under a new publisher, so any figure you compute today has a short shelf life. The four day measurement lines up: 2.24 dollars at that rate is close to nine thousand impressions, a little over two thousand a day, which is a fair description of what heavy agentic coding looks like.
Kickbacks has not published a user count next to that total, so there is no honest way to turn it into an average from the outside. The independent reviews that read the extension's own API report a lifetime average per registered developer far below the ten dollar payout threshold, which is the number that actually matters: for most people who install it, the counter never becomes money. Kickbacks has not published a user count, so treat that as a shape, not a headcount.
Now compare it to one hour of your own time
Here is the part that should end the economic debate. If your time is worth more than forty dollars an hour, then a full month of Kickbacks is worth less than one hour of you. Not one hour of billable client work: one hour of anything. And the first payout sits about three weeks away, which means the extension has to run in your editor, untouched, for about three weeks of daily use before it produces a number you can move.
Against that, every minute you spend installing it, checking the dashboard, explaining it to a colleague or debugging a patched editor is spent at a loss. The revenue is not fake and it is not wrong. It is simply too small to buy any risk at all. Hold on to that, because the rest of this article is about the price.
What we got right in June, and what we missed
Our first piece, Kickbacks.ai: ads in the Claude Code spinner, anatomy of a land grab with no lease, went out on 12 June 2026, the day after the launch tweet went viral. Two months on, three things in it held up. The land grab framing was right: Kickbacks monetises a surface it does not own, and that ambiguity is still unresolved. The copycat prediction was right: competitors appeared within forty eight hours, exactly as a thin technical moat predicts. And the caution on revenue was right: we said the per developer amounts would be small, and forty dollars a month is small.
What we missed matters more. We evaluated Kickbacks as a marketplace: take rate, demand side, inventory quality, platform risk. What we missed is narrower than a confession, and more useful. We did read the bundle in June, and we described the mechanism correctly: on the terminal path Kickbacks uses two settings Anthropic documents, spinnerVerbs and statusLine, while on the VS Code path it patches Anthropic's own extension bundle, loosens its Content Security Policy and pulls a new version every ninety seconds with no signature verification. We called that a supply chain risk in one line of the summary, then gave the rest of the article to take rates, inventory quality and platform risk.
A follow-up is only worth writing if it says that plainly. So: the security finding was already in our own copy, filed under a paragraph, while the business question got the headline. What the review adds is the detail that decides the matter, which is why the signature check never runs, and the sixty second loop that repairs the patch when you remove it. It does not. That is the assumption most readers would have made too, and it is precisely the assumption the security review takes apart.
What the security review found
The review, published by southsidechisolutions.com under the title Kickbacks.ai Security Review: VS Code Adware With a Payout Page, documents a combination of techniques that is unusual in a monetisation extension: file patching, self repair, a persistent security downgrade and unverified automatic updates. None of that proves intent, and we are not claiming any. It is the combination you are agreeing to that matters, not the intent behind it. The findings, in order of how much they should bother you.
On the VS Code path, it rewrites Anthropic's files
Kickbacks has two paths and they are not equally clean. In the terminal it edits your own Claude Code settings and relies on two fields Anthropic documents, so nothing belonging to Anthropic is touched. In the VS Code and Cursor panel there is no supported way to render anything inside the Claude Code webview, so the extension patches the files of the installed Claude Code bundle, adding JavaScript into the webview. In practical terms: another vendor's product on your disk is modified so that code it never shipped runs inside it. Nothing in the Claude Code update process expects that, which is why the next finding has to exist.
It repairs itself every sixty seconds
Because a Claude Code update, or a user with a text editor, would undo the patch, Kickbacks checks its modifications every sixty seconds and reapplies them if they are gone. That behaviour is what separates an integration from a persistence mechanism. When removing a change causes the software to put the change back without asking, you are no longer administering your own machine, you are negotiating with it.
The Content Security Policy stays loosened after you disable the extension
To let the injected code talk to a local process, the patch relaxes the Content Security Policy of the webview, opening a channel toward localhost. The CSP is the rule that decides which code a page may load and which hosts it may reach. It is one of the few hard walls inside an editor that renders web content. We reported this in June, from the vendor's own source comments, and the security review confirms it independently: the relaxation persists after the extension is disabled. Turning Kickbacks off does not put the wall back. That matters for anyone who assumed the toggle was the undo button.
Every ninety seconds, it downloads and installs a new version
The extension polls a remote server every ninety seconds, downloads a new version and installs it automatically, with no setting to switch that off. The destination is kickbacks-backend-gmdaqm2c7q-uw.a.run.app, a Google Cloud Run endpoint. Telemetry, according to the terms of use, cannot be disabled either.
Self updating software is not exotic. Your browser does it, on its own schedule, without asking. What makes browser auto update acceptable is not the frequency, it is the verification step. Which brings us to the finding that is the reason this article exists.
The empty public key, explained without jargon
The code contains a signature verification function. Having one is the right instinct: it is exactly the mechanism that makes automatic updates safe. The idea is simple. The publisher holds a private key only they possess and signs each release with it. The software on your machine holds the matching public key and checks that the file it just downloaded carries a valid signature from that key. If anyone swaps the file in transit or at the source, the signature does not match and the update is refused. You do not have to trust the network, the hosting provider or the domain registrar. You only have to trust the key.
In Kickbacks, the embedded public key is an empty string. There is nothing to check against, so the verification never actually runs. The function is present. The guarantee is not.
The plain analogy: it is a badge reader on a door with no badge list loaded. The reader lights up, it beeps, it looks like access control. Everyone gets in. The building still has a sign saying entry is restricted.
Now combine that with the ninety second loop. Now combine that with the ninety second loop. Your machine asks that server for a new version every ninety seconds and installs whatever it is offered, with no way to tell whether it came from the people who wrote the extension. The window between a bad build appearing on that endpoint and it executing on your workstation is therefore ninety seconds, with no store review, no human in the loop and no check in between. So the trust boundary is not "do I trust Andrew McCalip". It is "do I trust every party who could ever put a build on that endpoint": the publisher today, whoever owns the company after an acquisition or a shutdown sale, anyone who compromises the Cloud Run project or the build pipeline that feeds it. This is not about someone intercepting your traffic, since that endpoint is HTTPS only and the transport is already protected. A signature protects you against the source being wrong, which is the failure that actually happens in the wild: a stolen deploy credential, a poisoned build step, a maintainer who is no longer the person you trusted. With an empty key, none of those are distinguishable from a normal update. With an empty key, all of those are equivalent from your machine's point of view.
Two things should be said clearly. First, this is not an accusation of intent. An empty key constant is what a stub looks like when verification was planned and never finished, which is a completely ordinary thing to find in a product shipped in a week under viral pressure. Second, intent does not matter here. The property is structural: the code path is unenforced, the software runs on a large number of machines, and the mitigation is not shipped. A hole that exists by accident behaves exactly like one that exists on purpose.
The machine we are actually talking about
Unverified remote code execution is bad anywhere. It is worse here because of which machine is involved. A workstation running Claude Code typically holds the full git history of a codebase, .env files with database URLs and API keys, cloud provider credentials, SSH keys, package registry publish tokens and authenticated browser sessions. In agentic setups it also carries standing permission to run shell commands. In most companies it is the highest value endpoint in the building and the least monitored, because it belongs to the one person who would notice, and that person is busy.
It is also the machine with the most reach. Publish tokens point outward to your users. Cloud credentials point outward to your infrastructure. That is why supply chain attacks target developer laptops rather than servers: the laptop is the shortest path to everyone downstream. When we scope backend work, signed releases and pinned, verified dependencies are not a nice line on the checklist, they are the checklist. The same discipline applies to any API or backend build: what decides whether a system is safe is rarely the feature, it is what the deployment pipeline is allowed to accept without asking a human.
Anthropic has still said nothing
Anthropic, that is. One platform did move: the original listing was removed from the VS Code Marketplace, and the extension came back on 25 June under a new publisher, a new extension id and a new domain. Same product, new address. Remember it for two reasons. What gets pulled from a store can return under another name, and anyone auditing a machine has more than one string to search for. The extension modifies the files of Anthropic's own product, inside an interface surface Anthropic owns, with neither an agreement nor a prohibition. The silence reads two ways. The silence is not evidence of a position. What is on the record is only what was on the record before Kickbacks existed: in February 2026 Anthropic ran a Super Bowl campaign built on the line "Ads are coming to AI. But not to Claude." Whether that doctrine ever gets applied to a third party extension is unknown, and no timeline has been announced for finding out.
Whichever it is, the developer carries the exposure. Silence is not permission, and it is not protection. There is a mechanical version of the same problem: the day a Claude Code update changes that bundle in a way the patch does not expect, the sixty second repair loop keeps trying to reapply a patch to a file that has moved. That is a fight you do not want happening inside your editor while you are shipping.
So, do you install it?
No. Not on a machine that holds credentials, client code or production access.
This is not a close call and it does not require a security philosophy to settle. It is a trade. On one side, roughly forty dollars a month, first payment in about three weeks. On the other side, a component that rewrites another vendor's files, restores its own modifications when you remove them, leaves a security policy loosened after you switch it off, and installs remote code every ninety seconds without verifying who wrote it. There is no hourly rate at which that exchange comes out in your favour.
If you genuinely want to see it running, put it in a throwaway virtual machine with no credentials, no repositories and no logged in sessions, look at it, then destroy the VM. That is the only version of "just trying it" that costs what you think it costs.
If it is already installed
- Do not stop at disabling it. The review found the loosened Content Security Policy persists after deactivation, so the toggle is not the undo button. Uninstall properly, then verify rather than assume.
- Reinstall the Claude Code extension from scratch rather than trusting the patched bundle. Delete the extension directory first so nothing modified survives the reinstall.
- Confirm the sixty second loop is really dead before you consider the machine restored. Software that repairs itself is software that can outlive a half uninstall.
- Watch outbound connections to kickbacks-backend-gmdaqm2c7q-uw.a.run.app after removal, and treat any traffic there as an unfinished uninstall.
- Rotate what the machine could reach if it was a work laptop with production access: publish tokens, cloud keys, anything sitting in a .env file. Rotation is cheap. Deciding after the fact whether something was taken is not.
The lesson that outlives this extension
Kickbacks will be resolved one way or another: quietly patched, blocked by Anthropic, or abandoned when the CPM does not hold. The pattern will not be resolved, because the incentive that produced it is intact. AI coding tools have created a large, attentive, high value audience inside interfaces that have no third party extension model. Where there is no supported way in, someone builds an unsupported one, and unsupported means patching files, persisting changes and shipping updates outside any store review that would have caught an empty key.
If you are building a product on a surface you do not own, the problem is not that patching is unethical. It is that patching makes you responsible for a distribution channel with no reviewer in it. That is a serious engineering commitment: signed artifacts, a real key, a rollback story, an update mechanism the user is allowed to switch off. Most teams shipping a monetisation feature in a week are not staffed for it. We say a version of this to every founder building on top of somebody else's platform when we scope a SaaS product: what you cannot control, you must be able to survive, and what you install on other people's machines, you own for as long as it runs.
And if you are on the receiving side, deciding what gets into your development environment, the useful question is not whether the vendor seems trustworthy. It is whether the software still behaves acceptably the one time the vendor is wrong. An empty key is precisely what "wrong once" looks like. We use the same filter when we choose dependencies for AI powered web builds: verified sources, pinned versions, and no self updating component anywhere near a workstation that holds production keys. An empty key is precisely what "wrong once" looks like. We use the same filter when we pick dependencies for the products we build: verified sources, pinned versions, and no self updating component anywhere near a workstation that holds production keys. Send us the stack you are unsure about, in writing, and we will tell you what we would pull out and why, with a reply within 24 business hours. No call, no meeting.