fix(install): refuse conflicting Hunk installs - #960
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThe PR makes the curl installer reject competing Hunk installations unless explicitly forced and adds detailed conflict diagnostics, documentation, and regression coverage.
Confidence Score: 3/5The PR should not merge until managed-path aliases stop causing false conflicts and candidate version checks cannot block the installer indefinitely. Conflict discovery currently relies on lexical path equality and synchronously executes every discovered candidate, allowing valid self-installs to be rejected and a single blocking executable to stall installation. Files Needing Attention: install.sh Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
Start[Installer starts] --> Resolve[Resolve target binary]
Resolve --> Scan[Scan PATH and inactive nvm/mise installs]
Scan --> Candidates{Competing candidates found?}
Candidates -- No --> Version[Check managed target version]
Candidates -- Yes --> Forced{Force enabled?}
Forced -- Yes --> Version
Forced -- No --> Report[Report paths, versions, precedence, and removal guidance]
Report --> Refuse[Refuse installation]
Version --> Install[Fast path or download and install]
Prompt To Fix All With AI### Issue 1
install.sh:160
**Path aliases trigger false conflicts**
When the managed Hunk directory appears on `PATH` through a symlink, relative path, literal tilde, or another lexical alias, the exact-string comparison treats the managed binary as a competing installation, causing a normal install or upgrade to be refused even though no separate Hunk installation exists. This also affects `HUNK_INSTALL_DIR=/`, where `target_binary` becomes `//hunk` while the PATH scan constructs `/hunk`.
### Issue 2
install.sh:261-263
**Candidate checks can hang installation**
When any later PATH entry or known inactive nvm/mise location contains an executable named `hunk` whose `--version` invocation blocks, conflict reporting executes it without a timeout, causing the installer to hang before it can install, report the conflict, or reach the already-current fast path.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(install): refuse conflicting Hunk in..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| # Add one executable path to the newline-delimited conflict list exactly once. | ||
| add_hunk_candidate() { | ||
| candidate="$1" | ||
| [ -x "$candidate" ] || return 0 |
There was a problem hiding this comment.
When the managed Hunk directory appears on PATH through a symlink, relative path, literal tilde, or another lexical alias, the exact-string comparison treats the managed binary as a competing installation, causing a normal install or upgrade to be refused even though no separate Hunk installation exists. This also affects HUNK_INSTALL_DIR=/, where target_binary becomes //hunk while the PATH scan constructs /hunk.
Prompt To Fix With AI
This is a comment left during a code review.
Path: install.sh
Line: 160
Comment:
**Path aliases trigger false conflicts**
When the managed Hunk directory appears on `PATH` through a symlink, relative path, literal tilde, or another lexical alias, the exact-string comparison treats the managed binary as a competing installation, causing a normal install or upgrade to be refused even though no separate Hunk installation exists. This also affects `HUNK_INSTALL_DIR=/`, where `target_binary` becomes `//hunk` while the PATH scan constructs `/hunk`.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.There was a problem hiding this comment.
Fixed in 3737f97. Candidate and target paths now resolve physical directory aliases and executable symlink chains before comparison, and root installs construct /hunk rather than //hunk. Added regression coverage for a PATH symlink to the managed binary.
Responded by Pi using openai/gpt-5.6-sol.
This comment was generated by Pi using GPT-5.6 Sol
| printf '%s\n' "$hunk_candidates" | while IFS= read -r candidate; do | ||
| candidate_version="$(installed_version "$candidate")" | ||
| [ -n "$candidate_version" ] || candidate_version="unknown" |
There was a problem hiding this comment.
When any later PATH entry or known inactive nvm/mise location contains an executable named hunk whose --version invocation blocks, conflict reporting executes it without a timeout, causing the installer to hang before it can install, report the conflict, or reach the already-current fast path.
Prompt To Fix With AI
This is a comment left during a code review.
Path: install.sh
Line: 261-263
Comment:
**Candidate checks can hang installation**
When any later PATH entry or known inactive nvm/mise location contains an executable named `hunk` whose `--version` invocation blocks, conflict reporting executes it without a timeout, causing the installer to hang before it can install, report the conflict, or reach the already-current fast path.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.There was a problem hiding this comment.
Not changing this one. A portable POSIX-sh timeout requires launching and killing extra background processes, and the attempted watchdog adds process-lifecycle hazards of its own. The installer already executes the managed target’s --version; the added probes are limited to executable hunk candidates on PATH and known Hunk manager layouts. A deliberately blocking executable at one of those locations is outside the conflict detector’s trust boundary and can be removed or bypassed with --force.
Responded by Pi using openai/gpt-5.6-sol.
This comment was generated by Pi using GPT-5.6 Sol
There was a problem hiding this comment.
That’s a reasonable trade-off for a portable POSIX installer. The conflict probes are intentionally limited to executable Hunk paths the installer already treats as competing installs, and --force returns before invoking those candidates for version reporting. I’ll consider this concern addressed.
1 participant
Summary
PATHor under a known inactive nvm/mise install--force/HUNK_ALLOW_CONFLICTING_INSTALLS=1opt-out and emphasize restarting every existing terminal paneContext
Multiple package-manager installs can leave old terminal panes resolving an older Hunk even after
~/.hunk/bin/hunkis upgraded. The installer previously discovered only the first foreign binary and silently continued whenever its version differed.Fresh
mainalready contains the quiescent authenticated daemon migration from #933. I verified that current clients no longer retain the PID-based incompatible-daemon replacement path: incompatible incumbents are not signalled, and unauthenticated callers cannot invoke session controls or induce a restart.Validation
bun test scripts/install-sh.test.ts— 12 passedbun test src/session/broker/brokerClient.test.ts src/session/broker/brokerServer.test.ts src/session/agent/commands.test.ts— 49 passedbun run typechecksh -n install.shshellcheck -s sh install.shbunx oxfmt --check scripts/install-sh.test.ts website/src/content/docs/docs/start/install.md .changeset/quiet-install-conflicts.mdgit diff --checkTested on Linux; the installer regression harness stubs all published macOS/Linux platform pairs, but I did not run the installer on macOS.
This PR description was generated by Pi using GPT-5.6 Sol