Plugin4Shell is a plugin-integrity weakness disclosed by AIR Security that the researchers say they reproduced across Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI. The issue is not a break in Git’s cryptographic hash function. The problem is that affected plugin-installation flows could request a pinned commit without reliably verifying that the code ultimately checked out and executed still matched that trusted commit.
Direct answer: inventory the coding agents and plugins your team uses, identify the installed client versions, update to supported fixed releases where available, and verify current vendor guidance for products whose remediation state is still unsettled. A vulnerable client does not prove compromise, and updating the client does not by itself prove that previously materialized plugin code was clean.
What changed with Plugin4Shell?
AIR Security disclosed research showing that plugin source pinning could fail at the final verification step in several AI coding-agent ecosystems. In the tested scenarios, an agent could be told to install a plugin associated with a trusted commit SHA but still end up resolving and executing different repository content controlled by the plugin source owner.
That changes the trust model. A marketplace or configuration file showing a pinned SHA is not enough if the client does not independently confirm that the final checked-out repository state actually matches the expected commit before executing plugin code.

Which AI coding agents did AIR test?
AIR says it reproduced the Plugin4Shell technique against Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI. That does not mean every edition, every version or every installation of those products is automatically exploitable. Exposure depends on the affected client logic, plugin source and update path.
Why can Plugin4Shell become zero-click?
The risk becomes more serious when an already-installed plugin can update automatically. AIR says that in affected workflows a repository controller could change what the pinned reference resolves to, and a background plugin update could then bring the substituted code into the coding-agent environment without requiring the user to deliberately install the plugin again.
The zero-click description therefore applies to the demonstrated auto-update path after the plugin relationship already exists. It should not be interpreted as evidence that an arbitrary internet attacker can compromise any coding-agent installation without prerequisites.
Current Plugin4Shell fix status
The disclosure does not leave all four products in the same state. AIR reports Claude Code 2.1.179 and OpenAI Codex 0.146.0 as fixed. The Codex remediation is additionally supported by public reporting describing an OpenAI change that verifies the resolved checkout against the pinned commit.
AIR said that GitHub Copilot did not have a fix at the time of disclosure. TPS did not recover a dedicated GitHub or Microsoft Plugin4Shell advisory during the completed review that independently establishes a later fixed version, so that status should be treated as disclosure-time information rather than a permanent statement.
AIR also reported that the affected deprecated Gemini CLI would not receive a Plugin4Shell fix and described migration as the path forward. Current Google support and enterprise guidance should be checked before making that operational decision because the reviewed evidence did not establish one universal support state for every Gemini CLI user.
How to check your exposure
1. Inventory the coding agents
Identify whether your developers use Claude Code, Codex, GitHub Copilot, Gemini CLI or another coding agent with third-party plugin or marketplace support.
2. Record the installed versions
Compare the actual installed client version with the latest supported vendor release rather than relying on an old deployment record.
3. Inventory installed plugins
Record the plugin source, repository and installation path, especially for plugins obtained through marketplaces or remote Git repositories.
4. Apply fixed client versions
Move Claude Code and Codex deployments to the reported fixed versions or later supported releases. For Copilot and Gemini CLI, verify the latest vendor guidance because disclosure-time status can change.
5. Reduce unresolved plugin exposure
If a product remains without confirmed remediation, consider disabling or restricting third-party plugin use where operationally practical until the vendor provides a supported fix or migration path.
6. Treat patching and compromise review separately
Updating the client prevents or reduces future exposure only according to the fix scope. It does not by itself prove that previously downloaded plugin code was trustworthy.
Why a pinned SHA was not enough
A commit hash is useful only when the software consuming it verifies the final result. The Plugin4Shell research focuses on the gap between requesting a pinned commit and confirming that the checked-out repository state actually equals that commit.
The durable engineering lesson is straightforward: security controls must validate the artifact that will execute, not merely the identifier that was requested earlier in the retrieval process.
Does Plugin4Shell mean Git SHA-1 or SHA-256 was broken?
No evidence reviewed by TPS shows that Git’s commit-hash cryptography was broken. The weakness is in client-side source resolution and verification. The attacker model described by AIR relies on control of the plugin repository or source path and on how the affected agent resolves the requested commit.
Does a vulnerable version mean the machine was compromised?
No. AIR demonstrated a viable execution path in research. The reviewed evidence does not establish that every vulnerable installation received malicious code or that Plugin4Shell was exploited against real organizations in the wild.
Exposure and compromise are different states. A vulnerable version means the defensive control may be insufficient. Compromise requires additional evidence that malicious plugin content was actually delivered or executed.
Does updating prove previously installed plugins are safe?
Not from the evidence reviewed for this article. Current reporting does not establish that installing a fixed client automatically identifies, removes or replaces plugin code that may already have been materialized through the vulnerable path.
Teams with reason to suspect exposure should therefore preserve relevant plugin directories, update history, repository provenance and security telemetry according to their incident-response procedures rather than treating a successful client upgrade as proof that no earlier compromise occurred.
What should teams do now?
Prioritize version verification first. Claude Code and Codex users should move to current supported releases that include the reported fixes. Copilot and Gemini CLI users should check current vendor documentation because their disclosure-time remediation states were different and can change after publication.
Organizations that permit third-party coding-agent plugins should also review whether automatic plugin updates are enabled, which repositories those plugins trust and whether repository ownership or source integrity can change without another approval step.
What remains unknown?
No reviewed source established confirmed in-the-wild Plugin4Shell exploitation, a victim count, a universal indicator-of-compromise set or a complete product-by-product cleanup procedure. TPS also did not independently confirm every disclosure-time vendor fix state through dedicated vendor advisories.
What happens next?
The most important changes to watch are a GitHub or Microsoft Copilot remediation notice, Google clarification for Gemini CLI users, explicit Anthropic guidance, any change to the Codex fixed threshold, a CVE assignment, evidence of real-world exploitation and guidance for detecting or cleaning previously substituted plugin code.
Those developments should update this same Plugin4Shell canonical while the reader’s task remains determining exposure, remediation and possible prior compromise.
Verification note
TPS reviewed AIR Security’s original Plugin4Shell research, current independent technical reporting and GitHub’s public Copilot CLI plugin documentation. AIR’s demonstrated mechanism and cross-agent testing are the primary evidence. Some product-specific remediation states remain researcher-reported, and no confirmed real-world exploitation was established in the reviewed evidence.