You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@magpie.apache.org by "potiuk (via GitHub)" <gi...@apache.org> on 2026/10/25 16:41:01 UTC
[I] hook-manager: add a husky adapter [magpie]
potiuk opened a new issue, #1823:
URL: https://github.com/apache/magpie/issues/1823
The [hook-manager contract](https://github.com/apache/magpie/blob/main/tools/hook-manager/README.md) (#1819) defines how the secure agent setup integrates a git-hook manager: where its install puts the hook, how its home is split between sandboxed and host runs, and how the setup detects that a repository uses it.
prek is the only adapter so far.
This issue adds **husky** (JavaScript), which needs a strategy the shim cannot provide.
## What the source says (husky v9.1.7)
- **Install target.** `husky` (the install) runs `git config core.hooksPath .husky/_`: a *repository-level* value, written on every install (`index.js:14`).
A repository-level `core.hooksPath` overrides the global one, so git never runs the whole-user dispatcher in a husky repository, and with it the host-only homes.
magpie-setup's session-start hook (`drop_redundant_hooks_path` in `setup_preflight/isolated.py`) reports this value today but does not remove it, because it does not point at `.git/hooks`.
- **Trigger.** The npm `prepare` script (`"prepare": "husky"`, written by `husky init`, `bin.js:14`), so it runs again on every `npm install`.
npm puts `node_modules/.bin` first on `PATH`, so a `~/.claude/bin/husky` shim never sees it.
- **Skip.** `HUSKY=0` skips the install entirely (`index.js:9`) and every hook run.
- **Home.** No cache, but every hook sources `${XDG_CONFIG_HOME:-$HOME/.config}/husky/init.sh` (`husky:11-12`), so a hook runs code from the home directory.
Check whether any sandbox grant makes that file writable; if one can, it is the same escape the home rule exists for.
- **Generated hook.** `.husky/_/<name>` is `. "$(dirname "$0")/h"`, and `h` finds `.husky/<name>` from `$0` (`husky:3-6`): it must be exec'd by its real path, which the dispatcher already does for `.git/hooks`.
- **Detection.** A `.husky/` directory, or a `husky` entry in `package.json` devDependencies; hook marker `.husky`.
## What to do
Pick and implement one strategy, and add it to the contract's install-strategy table:
- **Chain to the repository's hooks path.** When the repository-level `core.hooksPath` is `.husky/_`, the session-start hook moves it to a Magpie-specific key (for example `magpie.localHooksPath`) and the dispatcher chains to `<toplevel>/<that path>/<name>` instead of `.git/hooks/<name>`.
husky rewrites the key on the next `npm install`, so the session-start hook has to keep doing it.
- **Or** recommend `HUSKY=0` for sandboxed installs and document how operators run husky hooks; weigh that this disables the repository's hooks for agent commits.
Then add the `husky` adapter to `tools/hook-manager/registry.json`, run `tools/dev/sync-hook-managers.py`, and update `docs/setup/secure-agent-setup.md` (the validated-behaviour table under *Whole-user with the per-repo dispatcher*).
## Acceptance
- In a husky repository under the whole-user setup, a commit runs both the dispatcher and the repository's `.husky/pre-commit`, and a failing husky hook still aborts the commit.
- Tests for the session-start rewrite and the dispatcher chaining.
- `prek run --all-files --skip workspace-pytest` and the affected tests pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] hook-manager: add a husky adapter [magpie]
Posted by "Kaap10 (via GitHub) via commits" <co...@magpie.apache.org>.
Kaap10 commented on issue #1823:
URL: https://github.com/apache/magpie/issues/1823#issuecomment-6538420782
Go ahead @leninworld, we dont assign issues.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] hook-manager: add a husky adapter [magpie]
Posted by "Kaap10 (via GitHub)" <gi...@apache.org>.
Kaap10 commented on issue #1823:
URL: https://github.com/apache/magpie/issues/1823#issuecomment-6412247705
A few thoughts on the two approaches:
- **Option A (Chaining via `magpie.localHooksPath`) vs Option B (`HUSKY=0`):**
- Option A is the only one that satisfies the acceptance criterion (*running `.husky/pre-commit` and propagating failures to abort commits*).
- Moving the repo-level `core.hooksPath` to `magpie.localHooksPath` during session-start and having the dispatcher chain to `<toplevel>/<that path>/<name>` preserves whole-user isolation without disabling repo checks.
- Option B (`HUSKY=0`) avoids rewrites but silences pre-commit hooks entirely during agent commits.
- **On `${XDG_CONFIG_HOME:-$HOME/.config}/husky/init.sh`:**
- `sandbox.filesystem.allowWrite` only grants `~/.cache/` (not `~/.config/`), so sandboxed commands cannot write to `init.sh`. Adding an explicit `Edit(~/.config/husky/**)` to `permissions.deny` would give clean defense-in-depth.
Option A seems like the right path to meet the acceptance goals.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] hook-manager: add a husky adapter [magpie]
Posted by "leninworld (via GitHub) via commits" <co...@magpie.apache.org>.
leninworld commented on issue #1823:
URL: https://github.com/apache/magpie/issues/1823#issuecomment-6531894683
I’d like to work on this if it’s still available. I plan to take the chaining approach (Option A): keep the whole-user dispatcher, capture the repository’s configured `core.hooksPath` (`.husky/_` for husky), and invoke the repository hook by its resolved real path, so both hooks run and a failing husky hook aborts the commit. The existing isolation safeguards should stay intact; if chaining turns out to conflict with them, I’ll raise it here before going further. I plan to add regression tests with real Git and husky covering both hooks running, failure propagation, repeated installs and linked worktrees. Nothing is implemented or tested yet. Could you assign this issue to me?
AI-generated planning note (Codex), reviewed by Claude.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org