Claude plugin: install the plugin version that matches the installed wt

Open
  • Is something wrong?
#4,702 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
cli, developer-experience

Research direction

Start by reading the existing Claude plugin install flow and the Pi extension that the issue cites as an example of embedding plugin files. Compare Claude Code's command plugin source with the proposed tag-pinned marketplace alternative, including how upgrades refresh the plugin and how failed fetches behave. Done means the installed plugin stays compatible with its wt binary after upgrades; the issue leaves the implementation choice open.

Written by the indexing model from the issue text.

Description

Problem

The Claude Code plugin is installed from the marketplace at main, by design (#2402, #3434). The binary usually comes from a release, through Homebrew or cargo install. Nothing ties the installed plugin to the installed binary, so the plugin can run ahead of the wt it calls. A claude plugin update, or Claude Code's own background update, can move the plugin past what the binary supports at any time.

Since #4305 this skew has a concrete cost. Every hook goes through wt config plugins claude hook, and on wt v0.80.0 or earlier, worktree creation and removal fail. Today the only guard is the README's minimum-version note.

Proposal

Claude Code supports a command plugin source (v2.1.229+). The marketplace entry names a command that prints a plugin directory as one line. Claude Code runs it on install and update, then once per session in the background, and reinstalls when the directory's contents change. That fits a CLI that ships its own plugin.

A subcommand such as wt config plugins claude path could print a directory holding the plugin for this binary's version. The files could be embedded in the binary, the way the Pi extension already ships with include_str!, or fetched at the matching tag. wt config plugins claude install could then register a marketplace whose entry is:

{ "name": "worktrunk", "source": { "source": "command", "command": "wt config plugins claude path" } }

After a brew upgrade worktrunk, the next session would pick up the matching plugin, and the plugin could never run ahead of the binary.

A smaller alternative: an install --ref <tag> option that adds the marketplace as max-sixty/worktrunk#<tag>. That pins the plugin but still needs a re-run after each upgrade.

The Codex plugin is installed from main the same way, so it has the same skew wherever Codex offers a comparable mechanism.

What I'm doing meanwhile

I use a local directory marketplace named worktrunk, so the plugin id stays worktrunk@worktrunk and wt config plugins claude install still sees it as installed. Its one entry is a command source that runs a short script:

  1. Map wt --version to its tag, refusing anything that isn't a plain vX.Y.Z.
  2. Shallow-fetch plugins/worktrunk at that tag into a cache, once per version.
  3. Print the path.

It works on Claude Code 2.1.318. After an upgrade, the next session's background run fetches the new tag. A failed fetch leaves the installed plugin in place. Happy to share the script if it helps.

This was written by Claude Code on behalf of zengzheqing

Dominant language
Rust
Stars
8.8k
Forks
315
Avg merge
1d 6h
Merged PRs (30d)
204

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from max-sixty/worktrunk

All issues in max-sixty/worktrunk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.