Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

test(guardrails): 4 block-root-delete-target allowed-roots assertions fail on Windows Git Bash

Open
  • Is something wrong?
#6,627 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
57/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
git, shell
Domain
testing

Research direction

Start with section 2d of plugins/guardrails/hooks/block-root-delete-target.test.sh and compare its allowed-roots fixtures with the Windows Git Bash path behavior described in the issue. Check how the test derives relative paths and handles / under MSYS; the issue also points to hook behavior as an open question. Done when the four assertions behave appropriately on Windows without breaking the existing Linux suite.

Written by the indexing model from the issue text.

Description

needs-human needs-triage

Problem

On Windows Git Bash, four assertions in plugins/guardrails/hooks/block-root-delete-target.test.sh (section 2d, allowed roots) fail. They fail the same way on origin/main (a1a836827) as on the #6542 branch, so the suite cannot go fully green locally on Windows. CI is Linux, and the Windows lane does not run this suite.

Failing assertions and output

FAIL: allowed roots: a relative root grants nothing (direct): expected exit 2, got 0
FAIL: allowed roots: a relative root grants nothing (dispatched): expected exit 2, got 0
FAIL: allowed roots: the root '/' does not allow a top-level path (direct): expected exit 2, got 0
FAIL: allowed roots: the root '/' does not allow a top-level path (dispatched): expected exit 2, got 0

Root-cause hypotheses (test fixtures, not the hook)

  1. a relative root grants nothing passes "${RDT_AR#/}" as a "relative" entry. On Windows, RDT_TOP comes from git rev-parse --show-toplevel, which returns the drive form (D:/worktrees/...). #/ therefore strips nothing, and the entry is a valid absolute root that correctly allows $RDT_AR/child. The test does not build a relative entry on this host. Evidence: git rev-parse --show-toplevel printed D:/worktrees/melodic-software-claude-code-plugins-fix-6542-allowed-roots-prefix.
  2. the root '/' does not allow a top-level path lists / and expects rm -rf /opt/rdt-allowed-x/y to stay refused. Under MSYS, / is the Git install directory (cygpath -m / prints C:/Program Files/Git/). That is not a filesystem root, so rdt_root_like does not drop the entry, and /opt/... lies strictly under it, so the delete is allowed.

Suggested fix

  • Build the relative entry from a path that is certainly relative on every host, e.g. strip the drive or leading slash with a host-aware helper.
  • Skip or re-target the / case on MSYS, where / is not the volume root.
  • Decide whether the hook should also refuse an entry spelled / on Windows. It names the Git install directory, which is probably never what a user means.

Related: #6020. Found while working #6542 (PR #6624).

Dominant language
Shell
Stars
22
Forks
2
Avg merge
5h 15m
Merged PRs (30d)
833

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from melodic-software/claude-code-plugins

All issues in melodic-software/claude-code-plugins

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.