fix(hooks): git pull and branch -d slip the CLI-steering guard #352

New issue

Closed

opened 2026-07-22 22:42:18 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-22 22:42:18 +00:00

(Migrated from codeberg.org)

The PreToolUse git-steering hooks (check-git-local.sh / check-git-remote.sh) route most raw git to the matching madt_* tool, but a few common verbs still pass through unblocked. I hit this doing post-finish housekeeping, where this whole compound ran with no guard firing:

git switch main && git pull && git branch -d <merged-branch>

Each verb has a madt_* equivalent, so none of it should have been raw git:

git pull (own repo) - not steered. check-git-remote.sh lets it through because raw pull is credential-safe (git strips the token from display), but credential-safety is not the same as sanctioned. It should route to madt_pull.
git branch -d <name> - the check-git-local.sh header already documents this as steering to madt_branch_delete, but it did not fire here. Likely a classifier gap when branch -d is the trailing segment of an && chain; worth confirming with a compound-command test.
git switch <existing-branch> - silent by design today (same-repo navigation). Lower priority, but "return to mainline after finish" is exactly where the reflex to shell out shows up, so it may be worth a gentle nudge toward the madtea flow too.

Keep it verb-specific, NOT a blanket git block: status / diff / log and same-repo navigation stay free. The ask is to close the pull and branch -d holes, and decide what to do about the switch case.

Repro: single Bash invocation, the three commands joined by &&.

The PreToolUse git-steering hooks (`check-git-local.sh` / `check-git-remote.sh`) route most raw git to the matching `madt_*` tool, but a few common verbs still pass through unblocked. I hit this doing post-`finish` housekeeping, where this whole compound ran with no guard firing: ``` git switch main && git pull && git branch -d <merged-branch> ``` Each verb has a `madt_*` equivalent, so none of it should have been raw git: - **`git pull` (own repo)** - not steered. `check-git-remote.sh` lets it through because raw pull is credential-safe (git strips the token from display), but credential-safety is not the same as sanctioned. It should route to `madt_pull`. - **`git branch -d <name>`** - the `check-git-local.sh` header already documents this as steering to `madt_branch_delete`, but it did not fire here. Likely a classifier gap when `branch -d` is the trailing segment of an `&&` chain; worth confirming with a compound-command test. - **`git switch <existing-branch>`** - silent by design today (same-repo navigation). Lower priority, but "return to mainline after finish" is exactly where the reflex to shell out shows up, so it may be worth a gentle nudge toward the madtea flow too. Keep it verb-specific, NOT a blanket `git` block: `status` / `diff` / `log` and same-repo navigation stay free. The ask is to close the `pull` and `branch -d` holes, and decide what to do about the switch case. Repro: single Bash invocation, the three commands joined by `&&`.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#352

No description provided.

Rows
Columns