Postman Quietly Installs Plugins into Claude Code and Codex, Then Goes Silent for 8 Days
Postman has tripped up again, this time not because of a price hike but because it touched someone else's stuff.
On the evening of October 24, a developer opened Postman on his computer, looked at it for a few minutes, and closed it.
The next day, he noticed his two commonly used AI coding assistants were not right.
One kept reporting login failures; the other, when given a task to write interfaces, would first go read Postman's usage instructions.
He investigated for most of the day, and finally found the answer in Postman's own logs.
The log said the installation was successful, and what had been installed were plugins for Claude Code and Codex.
The problem is, he never clicked to install anything.
A log that said "installed"
He used Postman 12.33.4.
That line in the log, with its trigger condition, translates roughly to an upgrade flow specifically for existing users.
In other words, as long as you are a logged-in existing user, open it once, and it takes care of the task on its own.
It left behind three things.
The first was in his Codex configuration: an added plugin marketplace, an instruction that gets read automatically on every startup, and it also flagged that instruction as trusted.
The second was in Claude Code's settings: from that moment on, Postman's plugin was set to enabled.
The third was in his home directory: an added postman command and a remote connection pointing to Postman's official side, though it couldn't connect.
The content of that startup instruction, in essence, was: when encountering interface-related work, first load Postman's specification.
It sounds light, but the weight is deep.
It's equivalent to writing a note inside someone else's tool: from now on, this kind of work defaults to me, and without your permission.
Ten days no one answered, one night the whole internet knew
On September 11, Postman launched this plugin repository.
On October 24, someone first caught the automatic installation in the logs.
In the early hours of October 26, this developer wrote a long report, with the word "severe" in the title.
The report had everything: the raw log, configuration screenshots, a link to the installer's source code, and six demands listed clearly.
Then nothing.
For eight whole days, the repository had no official response, and the report wasn't tagged with any label.
In the early morning of November 3, the first comment appeared, and within the next day, fifty more poured in.
In the early hours of November 4, someone took it to Hacker News.
By the time I checked, that post had over 1,400 points and more than 460 comments.
Later that day, the Chinese tech circle caught up, and a summary post got over a hundred thousand views within a few hours.
Three kinds of voices in the criticism
The first kind, the most common, are the ones packing up and leaving.
Their words are plain: I opened an API debugging tool and it changed my coding assistant.
Under these posts, three names appear most often: Bruno, Insomnia, and Milkman, all similar tools, free and offline.
The second kind, more calm, point more precisely.
They say the real vulnerability isn't Postman; it's that the trust we give AI is just a line of configuration, and anyone can write it.
Postman just happens to be the software that wrote it.
The third kind is rare but crucial.
They remind that the widely circulating headline says "attempted to share all API data," and that claim doesn't hold up.
This didn't happen suddenly
Postman's reputation has been slipping for years.
In October last year, it cut free-version small-team collaboration, leaving only one person per team, which already sparked a round of "why should we still use it."
In June this year, its own security page admitted that someone used a third-party service's account to take customer lists and quotes from its sales system.
That time it was a server breach; this time it's their own hands-on.
There are similar precedents. GitKraken publicly apologized in April this year for a similar action, with an official blog post saying they enhanced AI workflows but missed a key step.
The "shared data" claim doesn't hold
Laying out the existing material, there are only three layers.
The first layer is confirmed.
An existing user who opens once gets plugins installed, the two assistants' configs get modified, and the startup instruction gets flagged as trusted.
Two unrelated people reproduced it on two versions.
The second layer is unclear.
Whether that instruction actually ran or not, the two people disagree; one says there's a record, the other says there isn't.
The third layer has no evidence.
Uploading data is not supported by any log.
The material only goes as far as leaving a remote connection that can't connect.
The report's author explicitly states at the end that he does not claim data exfiltration.
Want to confirm whether you're affected
Three commands suffice.
grep -i postman ~/.codex/config.toml
grep -i postman ~/.claude/settings.json
ls ~/.local/bin/postman ~/.copilot/settings.json
To clean up, the client menu has an uninstall entry, under Help > "Postman CLI and Plugins".
However, some have reported that Copilot removal is not clean, leaving remnants in the config.
As of November 4, Postman's official account is still posting performance test content, with no statement on this matter.
The report's author makes only one demand: treat it as a product-boundary incident, not a documentation problem.
In the end, what makes this uncomfortable isn't that a company installed an extra plugin.
It's that we've long defaulted to granting permission to modify configurations to any software that reaches out.
Whether your machine is affected, feel free to share in the comments.
Issue address: https://github.com/postmanlabs/postman-app-support/issues/14370.