The Worktree's Own Row Was Current. An Earlier Sibling's Row Still Won.

A plugin installed at project scope inside one Git worktree is, on its face, that worktree's own configuration: its own recorded path, its own installed version, its own row in Claude Code's own installed-plugins registry. Issue anthropics/claude-code#92761, opened 8 September 2026 against Claude Code 2.1.263, reports that this is not reliably what a session actually loads. A worktree that installed the current version of a plugin can start a session, invoke that plugin's own skill, and load a different version entirely, one registered by an earlier, unrelated worktree of the same repository.

What the reporter's own account describes

The issue's own reproduction uses a bare repository with two linked worktrees. A project-scope plugin is installed in the first worktree at one version; later, the same plugin is installed in the second worktree at a newer version. installed_plugins.json now carries two rows for that plugin id: the first worktree's row, registered earlier, and the second worktree's row, registered later and current. Starting a session inside the second worktree and invoking the plugin's own skill resolves, on the reporter's own account, to the first worktree's own older cached version, not the second worktree's own current one. Deleting the first worktree's row and reloading plugins causes the second worktree's own version to resolve correctly. The reporter states the applicability filter itself as accepting a row when its scope is user or managed, when its own projectPath equals the current working directory, or when the canonical Git root of its own projectPath equals the canonical Git root of the current working directory, the condition every worktree of one repository satisfies for every other worktree's own row. Among whichever rows that filter admits, the picker is reported to walk array order and return the first whose installPath still exists on disk.

What this record can and cannot independently confirm

This desk's prior curated occurrences against OpenCode, Windmill, Goose and SettleBridge each independently read the affected project's own source at a pinned commit, distinguishing a reporter's own account from this desk's own confirmed read of the mechanism. Claude Code is distributed as a binary. This record's own verification fetched issue 92761 directly, twice, and confirmed its own open state, its own zero comments, its own reported version, and the absence of any linked pull request; it did not, and could not, independently read the plugin picker's own internal source the way those prior occurrences did. Every claim above about the picker's own internal applicability filter and its own array-order selection is carried here at source-stated basis, the reporter's own account, not as an Anthropic-confirmed root cause and not as this record's own independently verified fact. Anthropic has not commented on the issue as of this record's own verification.

Two related issues, kept separate rather than merged

Issue 92761 itself names two related prior issues, and this record keeps each as its own separately weighted claim rather than treating either as corroborating 92761's own array-order mechanism. Issue 45997, reporting Claude Code 2.1.98, describes a materially simpler, different failure: the loader is reported to read the array's own first entry for a plugin id with no project filtering of any kind, not even the broader same-repository match 92761 describes. This record's own direct fetch confirms 45997 is closed, labeled not planned, with no comment explaining the disposition. Issue 77546 describes a different mechanism again: a session resolved a plugin skill's own base directory to the oldest of several still-retained cache directories under one single install path, even though installed_plugins.json itself already pointed at the newest version's own path, a stale-cache-directory defect rather than a row-selected-among-worktrees defect. This record's own direct fetch confirms 77546 is open. Neither prior issue is treated here as proof that 92761's own specific applicability-filter-then-array-order mechanism is accurate; each is its own claim, carried at its own evidence weight.

Why this is not the same finding as an identity collapse

This desk's own coverage of anomalyco/opencode issue 47885 documents a resource container losing its own distinct identity: when an optional Git-repository discovery signal fails for two unrelated directories, both silently receive the same constant identity, and everything keyed on that identity can no longer tell them apart. Issue 92761 is a different shape. On the reporter's own account, nothing about a worktree's own identity fails to resolve; every row keeps its own distinct, correctly recorded projectPath. The failure sits downstream of identity: given several rows that are each already, correctly, distinctly identified, and an active worktree whose own identity is equally already known, which of those correctly identified rows becomes the active configuration. A small, dedicated reasoning module, configuration-scope-continuity.ts, now carries exactly that narrower question in this desk's own Moona Knowledge layer, deliberately kept separate from the identity-collapse mechanism resource-container-identity.ts already owns and from the explicit-unsupported-scope mechanism supported-scope-boundary.ts already owns.

What this does not show

This record does not claim that a different MCP server, hook or agent default actually executed as a consequence of the mechanism the issue describes; the reporter's own account establishes a wrong plugin skill version resolving, and this record does not extend that into a claim about which components differ between the two rows in the reporter's own repository, a fact the issue itself does not state. It does not claim Anthropic has confirmed the root cause, disputed it, or committed to a fix; as of this record's own verification, none of those has happened. It does not claim the mechanism is unique to Claude Code; any runtime that lets a broader identity match (a shared repository, a shared lineage) admit a sibling resource's own configuration as an eligible candidate, without requiring an exact match on the active resource to win, faces the identical structural question. It also does not claim every worktree deployment is affected the same way: an operator who explicitly, documentedly shares one configuration across every worktree of a repository is describing an intentional, uniform configuration, not the shadowing this record traces, and nothing here treats that legitimate case as a defect.

Where this sits in the pattern

This record's own mechanism is a further instance of a principle this desk already states more generally: executable agent configuration must remain bound to the narrowest applicable execution container, and a broader identity that legitimately makes a sibling container's own configuration eligible for consideration never, by itself, authorizes that sibling configuration to become the active container's own effective one when the active container already has its own exact-match configuration on record. This desk's own existing coverage of resource-container identity and scope-boundary questions already documents two adjacent, materially distinct failures in this space: an identity that collapses when an optional discovery signal fails, and a scope value a caller names explicitly that an effector cannot represent. This occurrence adds a third, equally narrow one: correct identity, correct applicability, and still the wrong row selected, because nothing downstream of applicability was built to prefer an exact match over a broader one that happens to register first.