Skip to content

fix: derive executable name from plugin ID for raw binary installs - #5

Merged
rhuanbarreto merged 1 commit into
mainfrom
fix/windows-exe-name-from-plugin-id
Jul 13, 2026
Merged

rhuanbarreto merged 1 commit into
mainfrom
fix/windows-exe-name-from-plugin-id

Conversation

@rhuanbarreto

Copy link
Copy Markdown
Contributor

Problem

proto install claude-code on Windows (plugin v0.2.0/v0.3.0) emits symlink warnings and running claude fails:

[ WARN ] proto_core::flow::link  Unable to symlink binary, source file does not exist
         source="...\tools\claude-code\2.1.207\claude.exe"
Error: proto::commands::run::missing_alternate_binary
  × Unable to run, alternate binary claude does not exist.

Root cause

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

#1 renamed the executable in locate_executables from claude-code to claude on the premise that "the downloaded binary is named claude" — but the download name is irrelevant; proto renames it to the plugin ID. That change is what broke v0.2.0+. (Installs made with v0.1.0, where the name happened to match the default ID, still work.)

Fix

Derive the executable name from get_plugin_id() at runtime and mark it as the primary executable — the same pattern moonrepo's own moon plugin uses for its raw-binary releases, with a code comment documenting this exact proto behavior.

This is robust to any plugin ID the user chooses (proto plugin add my-claude ... would install my-claude.exe and still resolve correctly).

Also bumps Cargo.toml version to 0.3.1 (was still 0.1.0, so register_tool reported a stale plugin_version).

Verification

  • cargo fmt --check, cargo clippy --target wasm32-wasip1, cargo build --target wasm32-wasip1 all pass
  • End-to-end on Windows in an isolated PROTO_HOME, registering the locally built WASM under the ID claude-test (deliberately different from the default to prove ID derivation):
    • install completes with no symlink warnings
    • tool dir contains claude-test.exe; bin/claude.exe, bin/claude-2.exe, bin/claude-2.1.exe and the claude shim are all created
    • both the shim and the bin link run: 2.1.207 (Claude Code)

After merge, tag v0.3.1 to publish the fixed WASM.

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.
@rhuanbarreto
rhuanbarreto merged commit e10ef50 into main Jul 13, 2026
4 checks passed
@rhuanbarreto
rhuanbarreto deleted the fix/windows-exe-name-from-plugin-id branch July 13, 2026 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant