Skip to content

Releases: BarretoTech/proto-claude-code-plugin

v0.3.1

Choose a tag to compare

@github-actions github-actions released this 13 Jul 16:22
e10ef50
fix: derive executable name from plugin ID for raw binary installs (#5)

Claude Code releases are raw binaries, not archives. When proto installs
a non-archive download, it renames the file on disk to the plugin's
configured ID (tool.get_file_name() in proto's flow/install.rs), e.g.
`claude-code.exe` for `proto plugin add claude-code ...`.

v0.2.0/v0.3.0 hardcoded the executable as `claude`/`claude.exe` in
locate_executables, which never exists on disk under the default plugin
ID. On Windows this surfaced as:

- "Unable to symlink binary, source file does not exist" warnings
  during `proto install claude-code`
- `proto::commands::run::missing_alternate_binary` when running `claude`

Fix by deriving the exe name from get_plugin_id() at runtime and marking
it as the primary executable — the same pattern moonrepo's own `moon`
plugin uses for its raw-binary releases.

Verified end-to-end in an isolated PROTO_HOME on Windows with an
arbitrary plugin ID: install produces no symlink warnings, and both the
`claude` shim and bin link run successfully.

v0.3.0

Choose a tag to compare

@github-actions github-actions released this 11 Mar 08:17
1dda41a
fix: rename package to claude_plugin for proto asset discovery (#2)

Proto expects the WASM asset name to match {name}_plugin.wasm where
{name} is the plugin ID used in `proto plugin add`. Renaming from
claude_code_plugin to claude_plugin so `proto plugin add claude` works.

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

v0.2.0

Choose a tag to compare

@github-actions github-actions released this 10 Mar 15:57
cb07e4a
Rename executable from claude-code to claude (#1)

* fix: add rust-toolchain.toml so build-wasm-plugin detects wasm32-wasip1

The moonrepo/build-wasm-plugin action checks for a rust-toolchain.toml
to determine the WASM target. Without it, it defaults to the deprecated
wasm32-wasi target which fails on Rust >= 1.78. Adding rust-toolchain.toml
with an explicit version lets the action correctly use wasm32-wasip1.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix: bump rust-toolchain to 1.93.0 (darling requires >= 1.88)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix: correct executable name and enable manual releases

- Fix executable name mismatch in locate_executables: the downloaded binary
  is named "claude" but locate_executables was referencing "claude-code",
  causing proto to not find the binary after download.
- Add workflow_dispatch trigger to release.yml so an initial GitHub release
  can be created manually (the "asset_missing" error occurs because no
  release with the WASM plugin binary has been published yet).

https://claude.ai/code/session_01MDcEp9zdPDEmwptZXUsWWb

* fix: track Cargo.lock and update dependency versions

- Remove Cargo.lock from .gitignore and commit it for reproducible CI
  builds. Without it, CI resolves dependencies from scratch which can
  lead to inconsistent builds.
- Update extism-pdk (1.2.0 -> 1.4.1) and proto_pdk (0.32.6 -> 0.32.7)
  to match actually resolved versions.

https://claude.ai/code/session_01MDcEp9zdPDEmwptZXUsWWb

* fix: pin build-wasm-plugin to v0.4 for wasm32-wasip1 support

moonrepo/build-wasm-plugin@v0 resolves to an older version that builds
with the deprecated wasm32-wasi target, which no longer exists in Rust
1.93.1. Version v0.4.2 added wasm32-wasip1 support.

https://claude.ai/code/session_01MDcEp9zdPDEmwptZXUsWWb

* fix: pin build-wasm-plugin to commit with wasm32-wasip1 support

The latest tagged release (v0.4.2 / v0) still uses the deprecated
wasm32-wasi target which fails on modern Rust toolchains. The fix
(commit 212061e) exists on their main branch but hasn't been released
yet, so we pin to the latest commit that includes it.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>