fix(install): install a hermes-acp launcher onto PATH

[SHL0MS]

What

setup_path() writes a hermes launcher into ~/.local/bin but nothing for hermes-acp. The hermes-acp console script from [project.scripts] lands in the venv, and the venv is not on the login-shell PATH.

ACP hosts resolve the agent by command name against that PATH, so a working install reads as missing to them. Concretely, Buzz Desktop 0.5.0 ships a Hermes preset that spawns hermes-acp and marks the runtime unavailable, which suppresses its row entirely. Zed and JetBrains configs that name the bare command hit the same wall.

This writes a hermes-acp launcher alongside the hermes one, dispatching to the acp subcommand. It reuses the existing pattern: same PYTHONPATH/PYTHONHOME clearing, same rm -f before cat > so an older symlink pointing into the venv cannot be followed and overwrite the console script (#21454). Both venv and non-venv branches are covered, and uninstall now removes both launchers.

Why a launcher and not a symlink

A symlink into venv/bin/hermes-acp reintroduces #21454 on the next install, and uv-generated console scripts resolve themselves through realpath, which stock macOS lacks. That is the reasoning already recorded in the comment above the hermes shim, so this follows it rather than inventing a second mechanism.

Verification

tests/test_install_sh_acp_launcher.py extracts the block out of scripts/install.sh with a regex and executes it under bash, the same approach test_install_sh_symlink_stomp.py takes, so the test cannot drift from a hand-copied duplicate of the shim.

Three cases: the venv branch produces an executable launcher that dispatches to acp, the non-venv branch does the same, and a pre-existing symlink at the target path gets replaced instead of followed.

$ pytest tests/test_install_sh_acp_launcher.py -q
3 passed

# revert the install.sh change only
$ pytest tests/test_install_sh_acp_launcher.py -q
3 failed

Neighbouring suites still pass together:

$ pytest tests/test_install_sh_acp_launcher.py \
         tests/test_install_sh_symlink_stomp.py \
         tests/test_install_sh_pythonpath_sanitization.py \
         tests/hermes_cli/test_uninstall_node_symlinks.py -q
14 passed

End to end on macOS, the generated launcher answers initialize over stdio:

{"agentInfo":{"name":"hermes-agent","version":"0.19.0"},
 "agentCapabilities":{"loadSession":true,
 "sessionCapabilities":{"fork":{},"list":{},"resume":{}}}}

Note on the host side

Buzz can also resolve the preset as hermes acp, which fixes this for installs that already exist. I opened block/buzz#3334 for that. This change is still worth having on its own: it makes the hermes-acp name work for any host that expects a dedicated ACP binary, without each one needing to know that Hermes exposes ACP as a subcommand.

[teknium1]

Merged via PR #73501 with your authorship preserved on both commits (a7d5147 — the install.sh launcher, and fda7714 — the Buzz permission-auto-approval warning). On top of your fix we added a hermes update self-heal so existing installs gain the hermes-acp launcher without a reinstall, plus a Buzz Desktop section in the ACP docs. Thanks for the thorough work on both sides of this — the login-shell PATH probe in your writeup made this an easy verify.